Skip to main content

a detour into offline messages...

A key feature that I recently added to the collaboration API (about 10 days ago) is an offline messaging capability. If you are a user of yahoo messenger you know how this works, when you are offline users are able to still open an IM window and send a message that you can then read when you log back into the system. I wanted to perform something like this since I finished the main implementation of the collaboration API almost a year and a half ago but I pushed it back , now that I am near the end I realized the 3 days it would take to code it was well worth the potential benefit it would bring to the users (and indirectly to the company!)

The offline messaging allows each User to control who can send them offline messages, unlike the yahoo thick client in which I periodically receive spam messages from users who are not on my contacts list. In my implementation, a User has 4 options that other Users can be given with regard to offline messages:

  • Offline messages disabled
  • Contacts offline messages only, notification off
  • Contacts offline messages only, notification on
  • Any User offline messages, notification off
  • Any User offline messages, notification on

In addition to these options a User has a stealth mode option for when they are online, this allows them to come online silently without notifying their contacts (or any Users browsing profiles) of their presence. If a User is in stealth mode, naturally they appear offline to the offline messaging code and thus are subject to receiving the offline messages while online. This gives them the discretion to do nothing, respond to the User by private message or email. The User Settings page displays the status of Users based on the above mentioned settings, I discovered that the logic was all screwy...the offline notification settings were mixed up and would indicate a User was online when he should have been indicated as offline, when online the display link allows sending a private message as opposed to an offline message even if offline messages are disabled (this was another pathology). After looking into the code I realized one thing quickly, I need to clean up a bit! The conditional statements were not aligned very well, I soon discovered the issue and fixed it. I noticed one aspect of symmetry observant designs that employ method polymorphism and combinations of hierarchical and compositional class relationships is that the savings on the class level can turn into some interesting conditional relationships. The use of simple integers as attribute fields in the classes saves a great deal of code in that the class ends up having many attributes but these various dimensions when put together in the client code inspire the creation of conditional statements to build the desired behavior. Case in point with regard to the problem mentioned above was that several attributes of the user object were conditionally tested to determine which of the links (offline message or private message or conference or eject...etc.) displayed on the settings page, this led to some clauses containing up to 3 sub conditions, though this results in rather imposing looking conditions at first...with proper condition design (making sure to take advantage of short circuiting) this leads to rapidly executing conditions tailored to exit at the rate of highest likelihood given the condition sub conditions.

All that said, I am still noticing a great deal of places for optimization of the code to squeeze it down to as few essential bits (characters) as possible. Since the client code in my framework runs mostly in jsp templates, squeezing down the bits directly aids performance over the distributed cluster in the long run and that directly reduces costs for operating the business...all great things.
Time to get back to the implementation...


Popular posts from this blog

On the idea of "world wide mush" resulting from "open" development models

A recent article posted in the Wall Street Journal posits that the collectivization of various types of goods or services created by the internet is long term a damaging trend for human societies.

I think that the author misses truths that have been in place that show that collectivization is not a process that started with the internet but has been with us since we started inventing things.

It seems that Mr. Lanier is not properly defining the contexts under which different problems can benefit or suffer from collectivization. He speaks in general terms of the loss of the potential for creators to extract profit from their work but misses that this is and was true of human civilization since we first picked up a rock to use as a crude hammer. New things make old things obsolete and people MUST adapt to what is displaced (be it a former human performance of that task or use of an older product) so as to main…

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

Live Coding Exercises: How NOT to hire potentially Brilliant Engineers.

I've intimated this view before but, I abhor "live coding" exercises for engineering interviews and will never have them as part of any interview process I conduct. They are simply unrealistic to real world engineering in every possible way, they only test familiarity (or luck) with a tiny subset of solution methods to a specif subset of problems...that you either "nail" or get spectacularly wrong depending on who is observing you.

They are mostly entirely unfair to the candidate on top of the pressure of having a gun under them while coding, only in the most extreme cases is coding under the gun and that's just competitions where the code is far from real world engineering why test for general coding ability with such tests?? Stupid.

I posit, it is significantly more effective to see examples of a candidates finished working code in the form of a project or projects they've created. How long it took some one to get some uber algorithm work…