Entry 7, Day 11
It seems that I’m more of a writer than a coder in this little endeavour. Well, old habits die hard, I wrote quite a lot of stuff several years ago, although not really technical. Anyway, this is good. Before you sit to code in the new projects, there are some stuff, you need to discuss with other devs, the Product Owner, Stakeholders/Clients, right? (Yes, devs can talk to Stakeholders directly, even though the PO is their default world interface. It can be very beneficial to the project). So now, let’s wander into the unknown lands of dragons. The enterprise (and less enterprise) technologies. There will be a lot of links.
Usually, there is a number of so called “technologies”, you will want to use. Theoretically, you can write an application using almost pure Java on top of application server (or what the hell, even without the server, just play with sockets manually), but it is impractical to say the least.
Under normal circumstances, the technology choice depends on what you want to achieve, what are the skills in the team at your disposals or other external factors like deals with big nasty software corporations. Since I’m my own client, I’m free to do what I please. I will go for some healthy mix of things that are suitable, fun, that I want to learn, and that I already know, and want to know better. Using only unknown technologies might be more beneficial from the learning point of view, but being struck at every aspect of the application might not be funny (not that I’m a pessimist, but I’ve seen stuff…). So I need some fields, where I know I can go fast to repair my ego if needed.
So, the main technology I will use is Java 8 language, as I’ve mentioned in the previous post.
Of course, since we are talking web application, the backbone of everything is HTML, this is what the user receives at the end.
There must be some kind of presentation technology (unless you are writing some purely backend EDI system or something similar). If you are truly old school, you can go with JSP pages. A bit more modern approach would be JSF or Velocity. There are plenty fish in the sea.
Client likes the application to be responsive. So instead of reloading the entire page, you can do things in the browser, instead of on the server. We can go with JavaScript, Dart, or my favourite: GWT. Actually GWT will do the job with both static and dynamic web content, and it is a Java compiled to JavaScript. I’m a big fan.
Then there is (usually) the framework that simplifies things (or complicates, depending on the framework and usage). Spring is the choice here, since it’s tremendous popularity in recent times. I’ve used it quite a bit, but there is still much to learn for me.
There is an object-relational mapping framework, Hibernate being popular choice.
Those are the core technologies. There will probably be many more, but we are not doing Big Design Up Front, remember? I will add and comment on new stuff as needed.
By the way, I think the word technology is sometimes an overkill when it comes to software. Nuclear bomb is a technology. Internal combustion engine is a technology. Microprocessor is a technology. Although Wikipedia says that technology is “collection of tools, including machinery, modifications, arrangements and procedures used by humans”, it seems to me that a piece of software written by a guy over several evenings while drinking beer shouldn’t be called that. Not that I don’t respect contribution to mankind well being, but there is a matter of scale. Probably “library” is sometimes a better word than “technology”.