Posts Tagged ‘programming’
I was reading ESB in Action* while preparing to implement Apache ServiceMix and was interested to read about JiBX, which is a tool for binding XML data to POJOs (Plain Old Java Objects). What it immediately reminded me of was Hibernate, which does ORM (Object Relational Mapping), and the possibilities there were for integration. This brought the thought to my head that together they could be used to create a WebService which could expose features of the database easily.
A search brought me the view of a Hibernate developer who pointed out in 2004 that there was a “impedance mismatches here: object/relational and object/hierarchical.” And I believe that would be true if it wasn’t for the fact that much of the data in relational databases is mostly hierarchical in nature. Even the core pattern of the embedded indexing in Hibernate Search assumes that the data being indexed is a nested hierarchy or inclusion hierarchy. I won’t get started on the issues that Hibernate Search has due to this impedance mismatch, needless to say there are a number.
The JiXB documentation is quite clear, and makes it easy to implement.
It’s thought that programmers have a solitary existence, in hacker movies they are often depicted as being behind a screen in the dark working on their own. Even the popular media images of programmers that are loners. As any programmer knows this is far for the truth, collaboration mostly benefits development. Sharing tasks and bouncing ideas of other developers makes the end products better. Yet with the exception of discussions the actual development task is performed by one person behind one computer.
There are many studies which show that there are even better ways to work, collaboratively create and discuss. Taking all the benefits of working as a team and sharing knowledge reduced to one continuous process rather than incremental tasks. It’s called pair programming, and studies have shown pairs can deliver 127% of what they deliver working on their own.
I recently made myself a map of terms I had found related to J2EE. Most of these items aren’t completely unknown to me, and this list is far from complete.
– Denotes the definition of the anagram abbreviation
Image source: Java Logo – Wikimedia; J2EE Mind Map – me
Currently I’m developing something which has a learning curve, not so much because it is difficult to understand it, more because there are portions of it which seem illogical. I could delve into the issues I have, and this may become a more technical article, and that’s not what I want to discuss here.
The current project I’m working on has a reasonably complex business logic which it implements, adding to that a untried and unknown technology and it’s a receipt for a difficult sprint – meaning it’s difficult to correctly estimate the complexity of tasks within the User Stories. This makes it ideal for applying Test Driven Development. The advantage of TDD in this case is that an assumption is made when writing code, expressing this assumption in a test before writing the code makes it easier to verify this assumption.
Programmers, including me, are very good at “thinking of problems that don’t exist, and fixing them.” Test Driven Development gives me the advantage that I can express my expectations in a test, and assert the requirements which need to be met for a test to pass or fail. In this way I can postpone the fixing of this fictitious problem until the time that an issue occurs.
An added advantage is when issues occur. Programmers – like me – are often focused on the details of the implementation, which means that we will see potential issues and blame side-effects of the current code rather than focussing on the issue which is occurring. Creating incremental tests as evidence that the code is working correctly can help bolster your position and support your argument that the error is outside your code, it also has the advantage that other developers will immediately see that their changes are causing side effects. This is far more effective than creating a one-time proof.
Image source: Jerry Wong
“What I did for a project I was working on was I create a LD_PRELOAD library which overloaded the i/o operations and used gz and bz2. This could easily be adapted to overload with encryption library functions rather than compression libraries. You can also use this to keep the bash history in memory using a shared memory location.“
What I did which inspired the message above was to replace a number of functions – including read, write and lseek – with custom functions. What the underlying custom code did was fingerprint – using the magic file – the file to discover which compression mechanism was being used for an existing file, and when creating a new file it would use the compression based on the value set in an environment variable. The file was never extracted to and only held in memory as these were mostly streamed to and from disk compressed, which means that with a little tweaking that these could include a stream cipher, provided the key is long enough to avoid stream cipher attacks.
For completeness I’ll add here that the code supported the formats listed below, and a number of other historic formats and others that I don’t recall:
- pkzip (deflate)
Somebody else’s LD_PRELOAD examples can be found here: LD_PRELOAD fun
Image source: John Davey
In a previous article this week I mentioned that I wanted to create an A/B Testing PoC for myself, something I could use to see which item was more effective on my site. This is a pretty rough piece of code, which means that you will need to get a programmer to have a look at it. The image you see on the write is dependent on whether you are A or B, the underlying link also points do a different location.
You can try it out by clicking on the image.