Simple editing with JED

A while ago when I was giving Slackware Linux the first tries I came across this tiny, very functional and very powerful text editor, JED.

JED is a minimalistic text editor for the shell that emulates Emacs in most of its useful functionality, is not as powerful as Emacs itself but it has just enough for me.

• Syntax highlighting 
• Key bindings
• Buffers for edition
• Contextual shell menus
• Very lightweight 
• And some other features

It might not be an IDE, but it's my favorite tool for editing text via SSH, or when I'm doing something small and I just want to do it as fast as I can. 

Give it a try, hopefully you will find it useful.

References

• Home page http://www.jedsoft.org/jed/
• Quick guide http://www.cs.cmu.edu/~jeliza/work/jed-intro.html
• Reference guide http://espec.ppgia.pucpr.br/doc/editores/jed/quickref.html

Development tips

I've worked in some projects so far and I learned some things that can save you a lot of time even if they sound very expensive. These tips are meant for small/medium size projects, perhaps you can apply them to big projects, but I'm not sure.

1. Revision control system from the beginning.
2. Define your goals and milestones, even without dates.
3. Define what you are going to build, with use cases or user stories, or just use whatever you feel comfortable with.
4. Define an architecture, don't go on without this. The architecture must define the form of the system, not the details.
5. Define the contexts you are going to be working on, this means that you have to separate your project into smaller micro-projects (if it applies).
6. Define your frameworks/libraries stack.
7. Define your project(s) structure, this involves folders and files.
8. Define your automated build scripts, something like Gradle would do it.
9. Think in the tests before the implementation, if it's testable, it's implementable.
10. Use continuous integration from the beginning.
11. Keep you source files small and readable.
12. Periodically check your system and update the architecture if some changes have been made.

I omitted several things, but I consider these the most important from a developer's perspective.

I didn't have this information at the beginning because I was too lazy to read about it, and had to learn it the hard way, by suffering the consequences...

Projects worth looking at

For a while I've been reading about the term Software Archeology from different media channels and I find it very valuable. Especially if you are trying to do something interesting with your projects, in those cases is a very good idea to checkout some very well written applications.

Rails
If you want to see what Ruby can do, this is the project I recommend. It has several gems in it, including a very complete documentation.

Guava
Google has released several open source projects with high quality code and lots of functionality, this set of libraries are great tools when dealing with real-life applications.

Guice
A great CDI component that simplifies Spring into fine grained components that are extremely extensible. I use it whenever I can and it's really, but really cool.

Fitnesse
This is perhaps the application with more test coverage I've ever seen, a serious attempt to reduce the gap between user acceptance tests and testers.

You might have noticed that most of them are written in Java, I didn't have time to check some other languages, but for sure Scala and Clojure are my next target.

References

• se-radio: Software Archeology
• Interesting repositories at github

Binary tree implementation on Ruby

I was having fun comparing the code I did in my early programming attempts in Java, and thought about how much would it take to rewrite it now, but in Ruby.

As an initial attempt, I took the widely known Binary tree, I started with the test cases and then implemented the code for them, here's the result.


I can say that it took at least ~50% less effort compared to the Java implementation, and it looks good :-)

Dead code evilness

Working on several projects at the same time is really exciting, you have to administer your time-sheet between tasks and work with different people. Hence the diversity, different technologies and environments.
But there is something common between all those projects, dead code. Dead code can be classified in some few categories:

• Legacy code.
• Refactoring-result code.
• Patches.

It's really frustrating for someone during development to see some code like this:

• What does the '0' mean?
• Why is the first line still present there as commented code?
• Is it really important to have it there?
• Should I remove it?
• What about the other parameters?
• Why it was commented in first place?

  This can lead you to several problems if you don't know how to answer these questions. But then again, why would you? Wouldn't be better to have something like this?:



If it's dead code, I mean, it's already dead, it should be removed for the sake of other developers. If you are working with Revision Control Systems (and I don't know why you shouldn't), the commented code is not longer required, you can revert or reapply a patch whenever you want.

In summary, get rid of your dead code, kill it, burn it, bury it. 

Supporting short lived objects

While working on some projects with different environments and behaviors, I started liking the notion of short-lived objects. Besides, I read a lot in several threads from StackOverflow > http://stackoverflow.com/questions/631919/short-lived-objects.

I like this kind of objects because they are easy to control, debug, update, delete. The notion of having an long living object is state, but to keep that state among several instances and requests can be a real hell if you don't control it properly.

And as you may guess, concurrency is one of the things I don't like to deal with, I prefer to leave it to a framework or third-party concurrency manager.

Benefits:

• Easy to control
• Easy to code
• Easy to test
• Challenges your design skills
• Avoids singleton all over the place
• It enhances performance 

Drawbacks:

• If you don't control them, you can have an big object pool
• You have to take care of references and garbage collection
• If your design is bad, your objects will be bad as well.

Migrate Oracle backup script to H2 (mode=ORACLE)

Some work I've been doing today.

Quick and dirty LOC counter written in Ruby

A few weeks ago I needed urgently to measure some projects I'm interested in, but I didn't have an internet connection to download the latest application that would do the work for me. So, I decided to write my own LOC counter.

I didn't want to write it in Java because of the time consuming for it, and as I am learning Ruby, I just gave it a try.

Result

A very short and dummy implementation that took me nearly 15 minutes, reading some API docs and testing, I don't know how to express it, but it feels right. If I would have done it in Java would work even better, but I like this approach, clean and short.