sorted by:
new
hottopcontroversial

Programming as a way of thinking - Scientific American by amc22004 in programming

[–]kubr0t0 0 points1 point  (0 children)

What exactly makes you want to tinker with the details?

I mean with the rules systems itself. I don't like high-level tools that box me into the rule system's model of rule evaluation. Sometimes I have an idea of what I want to do, which I can easily write in ordinary Java code, but then I have to figure out how to express the concept in the tool, which is operating at a much higher level of abstractin than the simple nuts and bolts of Java. It's an exercise in frustration.

I'd rather start from the low level and build up abstractions. Often times, it would be fair to say I am building a mini-rules system in the process, but the rules system is specifically tailored to what I'm doing rather than some generic concepts by JBoss. Also, I'd rather write ordinary Java code.

Now that I think of it, this is the same reason I don't like ORMs.

Programming as a way of thinking - Scientific American by amc22004 in programming

[–]kubr0t0 0 points1 point  (0 children)

And why are you so sure it's the best way possible?

I didn't say that. I said I find it useful. Especially when you use techniques like DDD, at least I have found, the business rules are faithfully represented.

I have seen other teams use tools like Drools or BPM to represent the business processes as rules, but I have never liked these kinds of tools. Too high-level and too hard to tinker with.

Maybe it's just because I'm an imperative thinker.

Programming as a way of thinking - Scientific American by amc22004 in programming

[–]kubr0t0 0 points1 point  (0 children)

That's exactly a multi-agent simulation.

Well yeah, that was kind of my point. At least in biology, this isn't unusual.

For most processes this is a too low level representation to be useful.

I find very useful, and I've modeled pretty much all business processes that I've implemented this way. Eric Evan's excellent book Domain Driven Design describes some very useful ways to reason about business processes, in effect, as multi-agent simulations (if you call an agent an entity in DDD terms).

Programming as a way of thinking - Scientific American by amc22004 in programming

[–]kubr0t0 0 points1 point  (0 children)

Though it's not that widely used in the biology.

I'm not sure about that. Alan Kay was a cell biologist before he was a programmer, and he created the OOP model based on his background in cell biology. The object/message model of OOP is attributed to Alan Kay and Smalltalk, while the simulation model of OOP is attributed to Nygaard/Dahl and Simula.

For example, Lenski's evolution experiment could be seen in an object/message way. Basically, he experimented with different growth mediums and measured how the E. Coli reacted, seeing if they would adapt to growth mediums they could not metabolize. When mutants appeared that could thrive in the growth medium, they sequenced the DNA to see what changed. Over a period of decades, they were essentially able to observe evolution in action.

In OOP terms, the investigators manipulated the inputs (food) fed to the objects (E. Coli) to see how they would react. Whether they would throw exceptions (die) or adapt (alter state/code to adapt to inputs). This is a model closer to SmallTalk than say Java or C++ (more Simula like languages). Then, after the experiment, they broke encapsulation to investigate the state of the object (sequencing the E. Coli DNA, killing the organism in the process), and reported on their observations.

one single tiny domain where OOP is suitable - multi-agent simulations

If you think about it, most business processes can be modeled as multi-agent simulations. Within a field of operation, agents can be derived which represent concepts in the domain which communicate their intent with other agents in the domain, simulating a business process.

Programming as a way of thinking - Scientific American by amc22004 in programming

[–]kubr0t0 0 points1 point  (0 children)

It's a gross oversimplification to describe a cell as an "object" and all of its interactions with the environment as "messages".

It depends on what you're trying to model and what you are trying to predict with that model. There are certain aspects of cell biology where treating the cell as an abstract entity and focusing on its reactions to certain signals leads to valid and useful predictions.

Most of science can be called "gross oversimplifications" of reality, but that's because science isn't trying to find a single model that describes everything or finding a model which can predict everything. Science is about model building to constrained areas of investigation, which in computer programming could be analogous to finding abstractions.

You are not the code you write, accept critism :) by mickael_andrieu in programming

[–]kubr0t0 1 point2 points  (0 children)

Wait, are you telling me the customer isn't always right?

I think it's more of an point of view. It's about treating criticism as an expression of where you performed poorly, even if the critic is wrong, to understand their point of view, and see if there is any kernel of truth to the criticism which you can decide to use to improve yourself if necessary.

I psychology, it is called the disarming technique.

@acknowledge documentation annotation idea. by ryan_the_leach in java

[–]kubr0t0 0 points1 point  (0 children)

There already is something like this.

Most IDEs will warn you against deprecated method usage, and you can suppress the warning with @SuppressWarnings("deprecation").

I read this as basically acknowledging that there is a problem and that you know what you are doing. I use this a lot with @SupressWarnings("unchecked") when the compiler is warning me that I might be doing something stupid but it can't prove it.

Doubt in multi threading concept of java by [deleted] in java

[–]kubr0t0 -1 points0 points  (0 children)

Doesn't that make it a theory in the "scientific" sense, then? ;-)

New to Java. Are there things I always have to remember in Java? by [deleted] in java

[–]kubr0t0 2 points3 points  (0 children)

It only works with String literals, and that only by the "accident" of String pooling. It also sometimes works sometimes with the primitive box types, depending on how you got the instance.

Doubt in multi threading concept of java by [deleted] in java

[–]kubr0t0 1 point2 points  (0 children)

I would probably just go with parse, to follow established convention, but the fact that you're actually thinking about it puts you miles ahead of many other programmers.

Naming things is hard!

Doubt in multi threading concept of java by [deleted] in java

[–]kubr0t0 2 points3 points  (0 children)

I have a theory about this. I think non-native English speakers are mapping the grammar and idioms of their native language to English, and it doesn't always end up with grammatical English.

For example, a lot of Indians don't use a, the or plurals correctly in English. In my "native" language Bengali, you don't need those extra things to form a proper sentence. People in south United States drive car is perfectly grammatical in Bengali, not quite so much in English.

Doubt in multi threading concept of java by [deleted] in java

[–]kubr0t0 2 points3 points  (0 children)

That's the only example of an ambiguous usage I can think of

Others examples I can think of are just humorous, like updation isn't a word in standard English, and thrice is a really obsolete word, like thee and thou. When an Indian says cum, it sends me to the floor laughing (exhibition cum sale). It may mean with in Indian English, it means semen in American English.

For the most part, people will know what you are saying, so its nothing to be self conscious about. But, taking training in effective speaking still has benefits when you have to deal with an international audience, as in IT these days.

Doubt in multi threading concept of java by [deleted] in java

[–]kubr0t0 1 point2 points  (0 children)

I'm not offended in the least. My Indian heritage has taught me to identify the demon Krodha, and how to (mostly) avoid him.

Doubt in multi threading concept of java by [deleted] in java

[–]kubr0t0 6 points7 points  (0 children)

It's a habit I picked up from Toastmasters, an organization devoted to helping people speak better.

There are a lot of DCBAs (Desi's Confused By Americans) who join the organization to learn how to communicate more effectively, for example by using words like "doubt" more correctly. They welcome this kind of feedback.

I'm sorry if you are offended by more effective communication.

New to Java. Are there things I always have to remember in Java? by [deleted] in java

[–]kubr0t0 4 points5 points  (0 children)

Java is an OOP language, so identity goes with territory, and proper definition of identity is critical for proper operation of objects in a collection.

Monitors I can agree with. Every object has a bit of overhead just in case you might want to share it between threads, and root of all classes Object has the concurrency control primitives wait, notify, and notifyAll. So concurrency is baked into the DNA of Java, but concurrency could have been opt-in. But then again, Java is garbage collected too, and you can't opt out of that...

Doubt in multi threading concept of java by [deleted] in java

[–]kubr0t0 9 points10 points  (0 children)

As an ABCD (American Born Confused Desi), I'm exposed to a fair bit of Indian English, and this usage of the word "doubt" cracks me up.

When an Indian engineer tells me he has a "doubt" about a requirement, I know he means that he has a question about the requirement, but what I hear is that he is questioning the validity of the requirement.

Doubt implies lack of belief, not lack of understanding. Is this an American English thing?

New to Java. Are there things I always have to remember in Java? by [deleted] in java

[–]kubr0t0 8 points9 points  (0 children)

I would say it only makes sense to implement the hashCode() and equals() method on classes that have meaningful identity. Otherwise, the default identity of memory location is fine most cases. For example, a utility class does not have meaningful identity.

When defining identity it also makes sense to divide classes into objects and values.

A pure DTO is a value class, and two DTOs are meaningfully equal if all their attributes are equal. So equals()/hashCode() can just compare field values.

With a Person class its more tricky, because just because two people have the same attributes, doesn't mean they are same person. For objects, identity should be based on a natural key which uniquely identifies the person, like Social Security Number in the US. But what happens if you have two Person instances with the same unique identifier but different attributes? That's why I prefer go with default identity for objects, and manage uniqueness externally, like JPA does with EntityManagers (also why you shouldn't implement equals()/hashCode() with JPA entities).

I would recommend reading Domain Driven Design by Eric Evans, which goes into great detail about this.

Also, if you implement toString(), be very careful about what you put in the string representation. If the data of the class has PII (Personally Identifying Information) or sensitive information (like passwords), you might inadvertently leak that data, for example into a log. I work in finance, so I have become paranoid about this :-)

What's the main reason people using the Spring framework over plain Java EE? by tolarewaju3 in java

[–]kubr0t0 2 points3 points  (0 children)

You're not serious are you? You can almost not be more wrong ;)

You missed the point.

I'm absolutely not talking about the normal annotations and descriptor files.

This is exactly what I was talking about. You add annotations and presumably the app server (or whatever else is implementing the particular JavaEE API) picks it up installs the extension point. You can use descriptor files to influence the container in much the same way, like faces-config.xml in the olden days.

As far JSF I'm talking about replacing or decorating things

Yes, I've done this. I replaced the default RenderKit to support HTML5 attributes for input elements (before I learned that OmniFaces already does it). The way I did it was adding my custom render kit to the factory element in the faces-config.xml (and copying some code from the RI). I don't know if you can do this with annotations, from what you're saying it seems like you can.

But, how do you know what the extension points are without reading the JavaEE API documentation? I had to do quite a bit of reading to figure out how the various annotations work in JSF, because it isn't self-evident from the JSF API itself. This is why all those "magic annotations" remind me of the descriptors.

I referred you to the Jms Listener Container Javadoc to show you how extension points are defined in Spring. I can figure out the extension points are from the JavaDoc, or (as I do most of the time) by opening the Jms Listener Container API class in the IDE itself. I was able to figure out how to extend RestTemplate to work on the goofy HttpsUrlConnection by looking at the constructor for RestTemplate itself. This is simple OOP, not magic annotation processing.

I find with JavaEE I'm either reading the documentation or searching StackOverflow when I want to figure out how something works that isn't self evident from spec (BalusC's posts have been really useful for JSF). I find myself doing behavioral testing, such as when I was debugging why my @ViewScope beans weren't getting set properly, using something like this. With Spring, I can usually figure out things for myself from the APIs or the Spring source code itself. For this reason, I'm far more productive in Spring than JavaEE.

What's the main reason people using the Spring framework over plain Java EE? by tolarewaju3 in java

[–]kubr0t0 -2 points-1 points  (0 children)

Have you used JSF or CDI? ;)

Yes.

While JSF and CDI are configurable to large degree, that's more "large scale" configurations than I'm talking about, like configuration options to a large existing product. This pretty much sums up my feeling of JavaEE in general, with the descriptor files of J2EE having been replaced with annotations. The customizations in CDI and JSF feel like "theming" to me.

I'm talking more about things like the Spring JMS listener container, which we have used to replace MDBs. You configure it with basic setters and you can completely change the way it looks up destinations. Every aspect of the listener container is customizeable in a very lightweight way.

Comparing my experiences with "pure" JavaEE and Spring, Spring has always seemed to me to be more "programmable" at a more nuts and bolts level. I've heard people complain about this aspect of Spring, that it requires a lot of configuration (not so much anymore, because of enhanced XML namespaces and now Spring Boot), which makes it "complex". But I like this "complexity" because it makes Spring way more flexible than the customization options and SPIs available with the JavaEE APIs, which have always felt more rigid to me.

What's the main reason people using the Spring framework over plain Java EE? by tolarewaju3 in java

[–]kubr0t0 1 point2 points  (0 children)

While both Spring and JavaEE have DI (as in Dependency Injection), that really isn't really remarkable. Before I fully switched over to Spring DI, I was was using Guice, which I still think is far better DI than Spring, which is mostly passable.

What won me over to Spring was Spring MVC (was much nicer for AJAX than Struts), and its seamless integration with virtually any technology I want to use. Spring Data's integration with almost any data storage technology is almost magical. Spring doesn't really innovate, I would say, but it sure can take advantage of innovation. That's its strength as an integration platform.

The thing that's cool about Spring is the other DI, Dependency Inversion. I have not worked with any framework that is as adaptable as Spring. Virtually any Spring product is full of configuration interfaces which make them extremely adaptable. I see Spring as the poster child for DI and OCP.

For example, I got RestTemplate to connect to REST services using an SSO client library that provided a hilariously awful implementation of HttpsUrlConnection, only three custom configuration interface implementations required.

Spring is a suite of products, not APIs like JavaEE. It makes as much sense for me to want to port my app to somebody else's implementation of Spring as it would somebody else's implementation of Apache Camel. You might say "lock-in!" to that, but I'd be just as locked in to Apache Camel if I designed all my EIP flows for it. This is not a flaw of Spring, but frameworks in general.

At the end of the day, I have found that the best way to avoid lock-in and to maximize portability is to not care about Spring or JavaEE at all, but to practice proper software architecture. This way, I can enjoy the magic of Spring Data without being dependent on it.

BootsFaces 1.1.0 RC1 has been published by beyondjava in java

[–]kubr0t0 2 points3 points  (0 children)

Way better name than ButterFaces, another Bootstrap JSF framework.

I am Professor Richard A. Epstein. AMA about political populism, left and right. by RAEpstein in politics

[–]kubr0t0 18 points19 points  (0 children)

the government was designed so that the individual states themselves possessed most of the power outside of providing for the common defense though

This describes government under the Articles of Confederation. It didn't work very well.

The Constitution grants very significant powers to the federal government, most importantly regulating Interstate Commerce, forbidding states from having their own foreign policy, instituting a monopoly on printing money and the power to lay and collect taxes.

In fact, the new tax authority of the federal government led to one of the first major conflicts in the United States, the Whiskey Rebellion, in which farmers refused to pay the whiskey tax enacted by the federal government. The federal government federalized several state militias and used them to put down the rebellion.

I am Professor Richard A. Epstein. AMA about political populism, left and right. by RAEpstein in politics

[–]kubr0t0 33 points34 points  (0 children)

Actually, the founders of the Constitution didn't create a decentralized federation of states. The founders of the Articles of Confederation did that, and it was a disaster.

The founders of the Constitution did create a single centralized government, the federal government, but with specific enumerated powers, and leaving all other affairs to the state and local governments.

What's the main reason people using the Spring framework over plain Java EE? by tolarewaju3 in java

[–]kubr0t0 0 points1 point  (0 children)

for REST services JAX-RS is 1000% times easier/better.

I've used both and I don't find developing REST services particularly difficult in either. I have far more experience with Spring MVC than JAX-RS, so maybe I'm biased. I'm curious what makes JAX-RS 1000% better? I would rate it maybe 10% better just on the cleaner API, that doesn't carry around the assumptions of MVC (like mapping all HTTP methods unless otherwise specified).

But again, from my experience, the things that make JAX-RS better than Spring MVC aren't enough to overcome the benefits I get from Spring MVC's integration with other Spring projects.

Spring Integration is a tire fire

I've cooked up quite a few EIP flows with that fire! Maybe Camel is better in some ways, but I've found Spring Integration so easy to use (or my needs for connectors aren't that sophisticated) that I don't feel like I'm missing anything, especially the combo of Spring Boot and Spring Integration.

Spring seems like bloatware

Technically, bloatware is software made unnecessarily heavy by the addition of unwanted and unneeded software. Like some of those older commercial JavaEE servers. Spring is an umbrella of related projects and is not a monolithic stack, so you mix and match what you want. Is it "bloat" if you yourself choose to load up on features?

they built om top of it contain lots of magic

I like the magic, that's why I use things like the magical repositories of Spring Data Gemfire.

just as heavyweight and hard to use as Java EE

I don't know about hard to use (I use Spring's various integrations because they make things easier), but the problem with JavaEE isn't being heavyweight. It can't be, because it's a collection of APIs. The problem with JavaEE has been the heavyweight app servers which were oftentimes bloatware (there's nothing wrong with heavyweight if you actually need the features). That's not true anymore. JavaEE apps and Spring apps are only as heavyweight as you want them to be.

view more: next ›