Earlier quoted context omitted.
yeah you are right, I learned servlets / jsps from Marty Hall's book and then just progressed from there. For smaller projects I usually start with Tomcat + Stripes + iBatis Sql Maps in order to minimize the learning curve. But no self respecting corporation would consider that stack (even though it is free, easy to learn and very fast).
What do you think are some of the factors behind the resistance to some of these alternative frameworks? I've heard good things about stripes. But it seems like almost every MVC framework other than Spring MVC is losing mindshare. I actually think Struts 2 is a nicely designed framework, but the association with Struts (which is actually an almost completely different framework) may have doomed it. Almost everyone us…
Ask HN: Enterprise Java guy needs advice on what to transition to
51–57 of 57 posts
Re: Ask HN: Enterprise Java guy needs advice on what to transition to
#52Given that you know Java, you could consider transition to Android - it is a lot simpler than enterprise Java (because it has to run on a phone) and most of the APIs have been reworked. But then that is just me.
Re: Ask HN: Enterprise Java guy needs advice on what to transition to
#53Given that you know Java, you could consider transition to Android - it is a lot simpler than enterprise Java (because it has to run on a phone) and most of the APIs have been reworked. But then that is just me.
I work in iphone development as a team lead for software tied to the enterprise stack. The backend/webservice is on the .net platform. We have an android team as well. We cannot for the life of us, find developers with deep backgrounds in software for android. Mainly beginners and entry level types. In the mobile space, I am sure there are companies on the java enterprise stack looking for android developers. The mob…
Re: Ask HN: Enterprise Java guy needs advice on what to transition to
#54Earlier quoted context omitted.
I've been thinking about DI in Ruby, and I've been trying to think of how I'd deal with the absence of DI in Rails. Here's a scenario... Suppose you have two different ways of gaining information about a logged in user. Let's say one goes to LDAP, and the other goes to an RDBMS. You'll be using one or the other depending on where the software is installed. So in Java, you create an interface that defines the methods…
Your question is more in regards to Ruby itself, and not Rails. You don't have to swap out implementations in Ruby. Implementations aside, when you do DI in Java, it serves two purposes: 1) instantiates an object and 2) wires it into another object. Remember that in Java, each class is in it's own file. In ruby, you can break classes into several files, but you don't have to. Ruby simply reads class declarations at r…
I'm kind of following you - unfortunately, I don't know ruby well enough to understand what you mean when you say class declarations are loaded as constants at run time, but I'll definitely look into it.
I think there's a third purpose to DI that you didn't mention. The container does instantiate an object and inject it ("wire it") into another object, but the real benefit is that you can externally configure which object to swap in. That last part might matter less in a language that doesn't have to be compiled but it can still be valuable if you have a lot of different implementations that need to be swapped in/out in different deployments.
The method you described for person - testing a conditional - do you mean you'd create a method with a conditional, and choose which implementation to use based on that conditional? I've done this, and it certainly works, but it isn't really a placement for DI (this sounds more like a factory method, though again I don't think that those really exist to the same extent in ruby since duck typing is much more flexible than static typing). My problem with this approach (if I understand it right, which I'm not sure I do) is that this would lead to a very long series of conditionals to load the right class. In rails, I'd probably be looking to pull them out into a yaml file (something like the applicationContext file in Spring).
Re: Ask HN: Enterprise Java guy needs advice on what to transition to
#55Earlier quoted context omitted.
Your question is more in regards to Ruby itself, and not Rails. You don't have to swap out implementations in Ruby. Implementations aside, when you do DI in Java, it serves two purposes: 1) instantiates an object and 2) wires it into another object. Remember that in Java, each class is in it's own file. In ruby, you can break classes into several files, but you don't have to. Ruby simply reads class declarations at r…
Thanks for your reply... I'm kind of following you - unfortunately, I don't know ruby well enough to understand what you mean when you say class declarations are loaded as constants at run time, but I'll definitely look into it. I think there's a third purpose to DI that you didn't mention. The container does instantiate an object and inject it ("wire it") into another object, but the real benefit is that you can ext…
Let's say I create a class called User. When ruby sees that declaration, it creates a constant called User to contain that object. When I create a new instance:
user = User.new
"User" is a constant whose value is the object/class. "new" is a method that calls the constructor (if one exists) and creates a new instance. The same applies when you call something like:
User.find
You're not calling find() on an instance, you're calling it on the object that's loaded into the constant "User". The class declaration "class User" is saying User is the name of the class; User is also the constant in which it's stored. It's also what allows you to reopen a class on the fly to extend it with more methods.
"I think there's a third purpose to DI that you didn't mention. The container does instantiate an object and inject it ("wire it") into another object, but the real benefit is that you can externally configure which object to swap in."
True, but I've never found myself switching objects out on a regular basis.
As you mentioned, the conditional approach probably isn't the best. What I'm assuming now is that you're based on your deployment, you might use a different bean factory configuration file? And this works as long as UserLdap and UserDb implement the same interface?
That being said, instead of sprinkling conditionals throughout user, you can dynamically assign User initially.
User = UserDb
OR
User = UserLdap
and as long as UserDb or UserLdap had a find() method, you could then call
User.find
Remember, User is now a constant that references the same value as UserDb or UserLdap
Does that help clarify?
Re: Ask HN: Enterprise Java guy needs advice on what to transition to
#56Earlier quoted context omitted.
> The language/tools are not the problem, it's the people/organization. The language is a problem, because Java was specially created for this type of organizations. And it is not surprising that Java attracts this type of people (fungible crowds having no pride in their craft).
I disagree that it's possible to paint all developers using this language with such a broad brush. By this notion everyone that uses Rails loves being a "ninja" and monkey patching.
But I'm not sure one can be a good programmer if Java (or any other mediocre language) is the only thing she knows.
Re: Ask HN: Enterprise Java guy needs advice on what to transition to
#57Earlier quoted context omitted.
Thanks for your reply... I'm kind of following you - unfortunately, I don't know ruby well enough to understand what you mean when you say class declarations are loaded as constants at run time, but I'll definitely look into it. I think there's a third purpose to DI that you didn't mention. The container does instantiate an object and inject it ("wire it") into another object, but the real benefit is that you can ext…
"class declarations are loaded as constants at run time" Let's say I create a class called User. When ruby sees that declaration, it creates a constant called User to contain that object. When I create a new instance: user = User.new "User" is a constant whose value is the object/class. "new" is a method that calls the constructor (if one exists) and creates a new instance. The same applies when you call something li…
It does help clarify this, thanks. It does still leave the problem that you have to specify the "type" in the code and can't swap it out. That said, I think this could probably be handled easily with a yaml file (just specify the class you want to instantiate every time a user is created)? I may try that some time.