Oct 15th 05
Posted by Remus Stratulat in Programming
I wanted to place on my site some pictures that I took at SIAB 2005. I thought at first to search for a free image gallery made in php but after that initial moment I have decided to create one myself.
So, today, to be “on the stre@m”, I’ve made an AJAX image gallery. It’s a simple and rough one but it has the nice feature of not refreshing the page content. The RPCs are made to a php page that reads the necessary informations from a database and delivers them back to the JavaScript.
And that is all for now. In time I will improve this utility on my site.
http://www.stratulat.com/hobby/gallery/
Aug 4th 05
Posted by Remus Stratulat in Programming
A programmer faces he’s problems through the tools he or she is using.
The romantic period of development.
Back in “those days” we were skillful programmers (well I was just in high school) taking the problems as they were. No tools (almost) were available for us. I was programming Basic and machine code on an old Russian made Sinclair Z80 clone. Now that was fun… But aside from my lack of experience in programming, it was a very slow process. There was no tool for code editing and I don’t think the word debugger was in my vocabulary yet.
In the faculty I’ve start using more evolved tools, like Visual Studio and Delphi but at my first job I have discovered Emacs. It was love at first sight. Back then there were three kind of developers: the ones that were using emacs, the ones that were using vi and the rest. And was not cool to be in “the rest” group. You were not being considered a real developer for doing drag and drop of buttons and other controls onto an interface and after that just change a bit the code.
Being a good programmer meant remembering a lot of C libraries and functions (STL was a breeze) or C++ and Java classes. Debugging meant investigating a core dump after a segmentation fault (that was a really nice error).
The competitive period of development
We have changed perspective and working places. The challenges grow up in size and the demands too. First time using a JBuilder (6) was bit frustrating but soon the rewards were far better than the lost of our “coolness”.
But how important is a good tool for a developer and what makes a tool to be a good or a great one?
- syntax coloring – I think this was the first feature that appear into a code editor. It is a helping hand in reading with ease the source code (aside code formatting but this is often the developer job the write a clear code)
- code completion – this is the feature that separates the good guys from the bad guys. Without a good and comprehensive code completion the programming is simply more time consuming as no person can remember every method and field in every class that he made. That is not speaking about the different third party apis that must be used into a project. Code completion comes now in different flavors. Some IDEs are trying to propose the best completion in the current context, others are offering the documentation along with the completion items.
- powerful search tool – while the code completion is in fact a search tool, helping us to easily find a method or field, in a lot of cases we must search for a text inside the current file or the current project. Regular expression searches have become now a standard in most of the IDEs and search and replace in multiple files is a very useful and used tool. From time to time you might encounter an innovation such as the file search tool from IDEA (Ctrl+N) that is looking for java files using camel letters.
- refactoring – I think this is kind of a “new age” feature. Changing a class name or method signature is becoming an easy task if you are using a refractory tool. No more searching for occurrences in other files.
- code snippets – this help in avoiding a lot of repetitive coding.
- versioning systems integration – as projects become bigger and the teams larger the necessity for a versioning system integration is obvious.
Along with this “basic” IDE features, each one of them comes with a lot of features that are related to the kind of development it is meant for. For example Together Control Center comes with a long list of preimplemented design patterns. If the IDE is meant for enterprise development it will come with specific tools to help developers to deploy their work on the server with ease. And so on.
Anyway, the time for romance has gone. Today you can spent a lot of time doing small, boring and unimportant tasks by not using the proper tool. A good IDE means better productivity for the programmer and more money for for his employer.
Jun 6th 05
Posted by Remus Stratulat in Programming
So we have seen that a big project relies on a lot of documents. One of this documents is the GUI mockup.
Graphical mockups are designs, for web pages or other products. Mockups typically use some or all of the actual graphics that will appear on the GUI. They are produced in a digital format (image, excel, visio, html) based on some specifications written by the analysts.
When a developer makes a JSP page for example, he or she must draw the interface according to this graphical mockup. But the analysts also make another document that must be followed by the developer: the interface requirements specifications. This document specify what components must appear inside the GUI (eg. the fields from the database that must appear and their labels). Strange enough, it does not specify the behavior, just the labels. Strange, as I think that the mockup should specify the content of an interface and how it is drown, because when you draw the interface, you can see how the labels will show into the page and you can establish their length for example. So the interface requirements specification should be the base for the mockup in indicating WHAT must appear onto the interface and HOW the components should behave, but not WHAT the labels are in the exact form.
Anyway, most of the time this two documents have different informations so the developer does not know what to follow. And the bugs start showing into the bugs reporting system.
Jun 5th 05
Posted by Remus Stratulat in Programming
The chaos theory as it is understood by the physicists is really about finding the underlying order in apparently random data.
But what is the relation with a software project?
Let’s suppose we have a company that is quite large and a software project is done using a certain standard. This standard requires a lot of documents to be written by various people. For example there are documents that describe the interface, documents that describe the database and documents that describe the use case. Everything is nice and proper organized.
Or is it? What dwells under the surface?
Sometimes working in this conditions is putting together the underlying random data beneath the apparently order.
We will dive head first into this in the following articles.
