Khaled Hussein

Eclipse is a powerful open source IDE. It is designed in a very extensible fashion that makes it attractive for software engineers to experiment with it. A few months ago, I started writing a number of Eclipse plugins. When I used Eclipse as my IDE, I liked a number of cool features such as automatic management of the package imports, some code refactoring snippets, automatic compilation, smart auto completion… etc.

Vim is one of the most powerful editors if not THE most powerful. It is very light weight. There is a huge community support for it. You can pretty much find plugins for most desired features. And if it isn’t implemented, it is easy to write it yourself.

Personally, I think it is unfair to compare Eclipse to Vim because this would be comparing oranges to apples; IDE to an editor. However we can definitely argue that Vim can be compared to Eclipse editing features. In this case, (for vim lovers like me) Vim wins for multiple reasons that I won’t list here because I don’t want to go into this war. So, how can we use Vim but also use the powerful IDE features?

Well, among other solutions, Eclim is just what I was wishing for. Eclim provides the best of both worlds. It enables vim to use features of a headless Eclipse. So, you still use vim to edit your files but you also get all the previously mentioned cool stuff. It is definitely worth a shot. I am going to use it in my next real Java project and I’ll inform you of my opinion after realistic use.

Let me know, what do you think.

Needless to say that query languages have gained a huge success across various application domains, especially business related solutions. Query languages are simple languages that are intended to facilitate making queries against repositories of resources such as data or information. For instance, most business applications use some sort of data storage such as a database or XML which can be easily queried against using SQL and XPath respectively.

The thing about query languages is that it enables programmers to describe the problem rather than how to solve it. This fact inspired a number of researchers to look at programs and source code as resources to be queried. As a result a new kind of query languages showed up called program query language. The purpose of program query languages is to enable programmers to make queries against:

• Source code such as ASTLog and JTransformer. (Static Analysis)
• Running Programs. (Dynamic Analysis)
• Both such as SOUL, PQL, and .QL. (Hybrid)

Programmers and researchers have found a number of substantial uses of program query languages. One of the most important uses is finding bugs and errors, especially the runtime ones. For example, forcing code practices, such as closing a stream after it’s been used, is hard to detect. However PQL uses a very simple query to detect such a problem among others.

For those of you who understand by examples, click here for examples from the proprietary .QL language website. Also, don’t forget that PQL is the open source alternative.

So, tell me what do you think about program query languages? would you use them? what for? are they really usefull as their authors claim? Please, share your thoughts

Recently, I have been working on a project that can be considered my first real test driven development experience. As the name implies, test driven development is an agile methodology that aims at producing code that has been fully tested. Another one of the most powerful advantages of test driven development is that if a developer modified the code, he can easily run the existing test suits and he would know if his modification broke any of the existing features in the code. Essentially, a developer starts thinking of the functionality that needs to be added to the existing code base. Then, before writing any code, he writes a test case (maybe a number of them) that will of course fail because the feature isn’t implemented yet. Then he would write the bare minimum code that would make the test cases pass. Then write more tests, then write more code to pass the tests …etc.

So, what’s the problem? Well, one of the main problems with Test Driven Development is testing private methods (assuming that you’re using an Object Oriented language). I googled the problem, and I found a number of solutions. Here is a list of the interesting ones along with the problems of each:

1. Change the access modifier of the method to public/protected/internal/…etc., run your tests, then change it back to private
   1. Once you change the access modifiers back to private, your test cases won’t even compile.
   2. If I decided that a specific method needs to be private, why would I ever want to change it to public. It seems like a dirty walk around the problem and violation to the developer’s intended design.
2. Philosophical solution: Test only public methods, which are assumed to call private ones.
   1. It is based on the unsolved debate of what unit testing really is.
   2. It sounds like “lets ignore the problem intentionally”
3. If you’re using JUnit4, you can create your test cases in the same class you’re testing, which means you have access to its private methods.
   1. It results in a large sized release of your project. Because you have all test cases embedded in your code.
   2. What if your test case needs to test two private methods separated in two different classes?
4. Use annotations/attributes/…etc.
   1. It isn’t a language independent solution
   2. Behind the scenes, these annotations change the accessibility of your methods. But again, this implementation is different in each language.
5. I’d appreciate it if anyone shares any other solutions?

Luckily, I was able to find another solution that seems to satisfy my requirements. Although the solution is generic and language independent, I’ll explain it referring to  Java. Before we go on, let me give you a quick introduction to the technologies that I used.

Aspect oriented programming is a technology intended to motivate separation of concerns. Usually developers refer to concerns as features that can be, but not necessarily, tied to the business logic. For example, logging, caching, exception handling, …etc. However, I think that it is safe to look at concerns as any feature that is required in your program. One of the most powerful tools that aspect oriented programming provides is called introduction. Basically, it means that you can introduce new fields, methods, or structure to your existing classes, which is the core tool behind my solution. [Have you guessed the solution yet?] Most language compilers have aspect oriented programming extensions. For example, AspectJ is one of the most common Java extensions that supports aspect oriented programming.

Alright here is how you can unit test private methods using aspect oriented programming:

1. Create aspects that introduce public methods to the class under test
2. In those public methods, you have access to all private methods and fields, call the private method and return the result.
3. In your unit test, call the public method which is just a simple wrapper to the private method.
4. Once your program is mature and ready to release, all you have to do is to build the source code without both of unit tests and AspectJ files.

Is it the best solution in the world? I don’t think so, and here is why:

1. If I ever wanted to release my test cases as well as my source code, I have to ask other developers to install a new compiler, because the test cases won’t compile without applying (weaving) the aspects into the code base. In my case, the compiler is AspectJ.
2. Developers in my team have to learn a new language constructs (aspects). However, I have to say that you can learn it in less than an hour. Probably, not master it ;).

Note: if you know of anyone that proposed this solution, please let me know so that I give him the credit for the idea. Also let me know if you’d like any sample source code to demonstrate the idea.

Please, share your thoughts!

Recently, I was involved in a number of projects that used Scrum. Just in case you don’t know, Scrum is an agile software development methodology intended to improve communication among team members. When using Scrum, each project has a backlog that contains all the goals and tasks that need to be accomplished. Team members start off with a sprint planning session. During this session, team members pull tasks from the backlog and put them into a so called sprint. Generally, sprints last 2 or 4 weeks and in this time, team members are committed to finish the tasks within the sprint. The most attractive part about Scrum is its daily meeting/stand up feature, in which team members (actually stand up) and answer 3 questions; (1) What was done yesterday? (2) What’s going to be done today? (3) What barriers are faced, if any?

A few days ago, it hit me, ‘Hey, why don’t I modify Scrum a little bit so that it can be applied to my personal life?’ Since then, I started researching previous experiences that used Scrum in different domains. Surprisingly, I found many altered uses of Scrum, which encouraged me to pursue my idea. For example, Michael Hicks and Jeffrey S. Foster, two computer science professors in University of Maryland, adapted Scrum to manage their research groups, rather than traditional software development;  their modified version is called SCRAM.

This past Monday, I started jotting down my backlog, which will definitely continue to be modified and improved over time. I also decided to conform to the following scheme for my personalized SCRUM:

• Each sprint should be completed within 1 week.
• Sprint planning should occur every Sunday evening.
• My daily stand up (comedy session??) should be conducted every night before I go to bed.

I have been applying this personalized Scrum for a few days now, and it’s been going pretty well, thus far. I’ll keep you informed with my critiques and thoughts every month until I stabilize everything.

Please share your thoughts!!!

Mailtrust held their hackathon number 6, which is the first for me. It was pretty exciting to pickup any project that you wanna work on, and try to finish it all from design to delivery in one day. My project was to create a generic notification API that can send alerts to email, jabber IM, or sms.

Since I have been working with ActiveMQ for over a month now, I decided to use it to queue the alerts. All alerts are described in an XML file similar to the following one:

<alerts>
 <alert>
 <priority>high</priority>
 <recipients>
  <recipient>
   <destination>someone@email.com</destination>
   <types>
     <type>email</type>
     <type>jabber</type>
   </types>
  </recipient>
 </recipients>
 <body>This is the alert message</body>
 <sender>
   <emailname>youremail@email.com</emailname>
   <emailpass>yourpassword</emailpass>
   <jabbername>yourjabberID</jabbername>
   <jabberpass>yourjabberpassword</jabberpass>
 </sender>
 </alert>
</alerts>

This XML file is passed to our API which parses the file, and queues a number of alerts based on its priority to different ActiveMQ queues. Then, we configured a number of Apache Camel routing rules that would route these alerts from ActiveMQ to different end points, such as jabber and e-mail.

The biggest problem with this XML file is that your e-mail as well as your jabber passwords are stored in plain text, which can be solved very easily. Just FYI :).

The project is written in Java, however, we implemented a php interface to it. Any other language can easily implement an interface to our API if it only parses the XML alerts document. This project will be released as an Open Source project after I remove some Mailtrust sensitive information. Everyone is more than welcome to use/modify/enhance/release the project.

Typically, you can run shell scripts remotely on your work linux machine if you have any of the following:

• VPN to your work network.
• Your work desktop has a public IP or port forwarding capabilities.

If you don’t have any of the above and you don’t have any access to your work desktop, keep reading.

Read the rest of this entry »

At Mailtrust, they tend to use ActiveMQ as their Universal Messaging System (UMS). That was the first time for me to start reading about messaging systems and the distributed handling of messages. This post is not about comparing ActiveMQ to other distributed messaging systems. However, ActiveMQ is an open source message broker that is written in Java; It supports communication over a number of protocols such as Stomp and OpenWire; and it is pretty cool :).

In this post, I am not going to dig into the details of their implementation. However, I’d like to mention that there is a good opportunity for freelance developers to enhance ActiveMQ by implementing a number of features.

Here is a scenario that highlights one of the most important concerns about ActiveMQ. A producer P1 sends a number of messages to two brokers (B1 and B2). There are two consumers on these two brokers respectively (C1 and C2). Ideally, if the producer sends 50 messages, then each consumer should receive 25 messages. With the right configurations and the approperiate dispatching algorithm, you can do this with the current version of ActiveMQ. If C2 processed only 10 of the 25, then there would be 15 messages pending in the queue. However, if C2 died after processing the 10th message, the pending 15 messages would remain at B2 and they won’t be forwarded to B1.

There are different ways of implementing this feature into the current source code of ActiveMQ. Aside from the details of how the code works, I am more interested in how we can separate our implementation from the source code of ActiveMQ. In other words, I don’t want our implementation to be affected by releasing a new version of ActiveMQ. In fact, I want our implementation to be pluggable to any version of ActiveMQ.

This is a typical separation of concerns problem. The good news is that there are several ways to do that. The bad news is that every method has its own pros and cons. For now, we think that we might want to use AspectJ as well as DRIVEL to embed our code into ActiveMQ.

Share your thoughts.

Yesterday I attended a very interesting Tech Talk at Mailtrust about semantic web. Manu Sporny introduced the idea behind semantic web and compared between Microformats and RDFa. Here are some thoughts and ideas inspired by the talk.

Manu demonstrated the importance of implementing semantic web from several perspectives. Surprisingly, he stressed the lack of interest from the community. Specifically, there isn’t enough participation to fully enable semantic web. I think that there is pretty good explanation to why this is the case.

Researchers try to find the technique to be used in order to describe the data on the web. Users, on the other hand, apply this technique and start implementing data descriptions. However, users face two obvious problems:

1. Describing data is a tedious and time consuming task.
2. Users face a lot of arguments about the accuracy of the description they provide.

Manu gave an interesting example of real-life scenario. In his business, he wanted to describe a song title using semantic web. He mentioned that it took them five and half months to solve the argument about tagging the title of the song using the word “title” or “audio-title”.

The good news is that there is a pretty interesting infrastructure that web developers and authors can start using. With that said, I think that the community needs to see killer applications that motivate them to do the hardwork of data description. The following ideas are pretty simple and intuitive, but they might lead to a combination of ideas to be the killer application.

1. I believe that authors might be interested in tools to help them create their pages (editors, validation tools, plug-ins to existing IDEs, …etc.)
2. Web browsers need more powerful ways to make use of these semantics. For example, fuzzbot does a good job on parsing the documents and so forth. However, more interesting tools can be driven from the use of the semantic information. Maybe, automatic synchronization of objects (event’s information online and your copy in your calendar).
3. For hardcore programmers and/or researchers, can we automate or at least simplify the process of describing meanings? Although that there are several research questions in the area of web semantics, this question is considered crucial to make substantial steps towards practicality.

I am pretty sure that almost all of these ideas are already implemented, but improving is the key to progress. If you are interested to discuss any of these ideas, similar ones, or related ones, please don’t hesitate to contact me. I always like to work on cool stuff with cool people.

Share your thoughts.