Welcome Welcome to our blog about all kind of topics that are related to software development. We blog about:
SOA, BPM, EDA, ECM and all the other buzz words. Beware some post might not be so common as you think. We are not scared to go against main stream thoughts.
Technologies like java, maven, springframework, OSGi and front end technologies and frameworks like jQuery, DWR, Flex.
Finally to make this happen we need tools and of course a Mac (well some of us do). So we blog about that as well.
Linked in We now have a linked in group, join the group if you are a regular reader and want to see who else reads this blog.
 |
By jettro, on August 30th, 2008
 This is a short post about again another tool for the mac. I was using TextMate as an external text editor. There were a few reasons why I liked it a lot. I am using it mainly for editing files without opening a full blown editor like IntelliJ or DashCode. Since I am doing a lot of java development, I have a lot of property files as well as xml files that I need to edit. I heard about TextMate and got curious, for me there were a few reasons why I liked TextMate a lot.
- Quick startup times
- Possibility to startup TextMate from the command line
# mate <filename>
- Integration with subversion
- Xml formatting
Today I decided to by TextMate, than I saw it was almost 50 euros. that is to much for me for just a text editor. Therefore I started looking for something else. I found the open source tools Smultron. My conclusion, TextMate is better but not worth the 50 euros when you compare them. I did have to integrate an xml formatter to get three of the points out of the four mentioned within Smultron.
read on to find out the small steps I had to take.
Continue reading Using smultron as a TextMate alternative
By jettro, on August 29th, 2008
This blog item gives you an inside scoop into the continuous integration environment at JTeam. You’ll learn about the why, what and how of continuous integration. The tools we use are mainly open source.
Why continuous integration?
A number of years a go not many people new the term continuous integration. That has changed a lot. All people at JTeam know what it is about and all projects use an environment that is set up to actually do continuous integration. For those that do not know what continuous integration is and those that need a short recap, we briefly explain what we think continuous integration is. Let’s start with the definition from Martin Fowler:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly
Key to continuous integration is delivering high quality artifacts. It is not the silver bullet, developers still need to create great code, but using a good continuous integration process helps finding bugs. Checking your quality standards a long the way increases the effect. Of course extra actions are still necessary. You can think about actions like: manual code reviews, performance tests, functional tests, etc.
JTeam has been using continuous integration from the start. Recently we implemented the second version of our continuous integration environment. We introduced new tools, the process however stayed the same.
Continue reading Continuous Integration (Again)
By freddie, on August 28th, 2008
Papyrus offers Rich Internet applications (RIA) for enterprise users with the same online and offline usability, layout and functionality as desktop applications
– One Single Definition – Central Version Management and Release Management – Multi Language – Text Editor – Without Additional Coding-
 It was quite a while back i did my last post but I am back and with great news. Since a while we have at ISIS Papyrus a new user interface technology called Papyrus Eye and we use it already at multiple customer implementations. The result where so good as also the responses we get on our workshop and demo`s that we now find it the right time to let the world know.
Its not my job neither my responsibility to do press releases so I will keep this post short and want everyone to look out to the press release the coming weeks. But if you are to curious you can always visit the Blog of our Chief Architect and founder of ISIS Papyrus Max J. Pucher. He wrote in his latest blog on the Papyrus Eye. You can find his blog on: http://isispapyrus.wordpress.com/2008/08/28/the-papyrus-eye-user-interface/
But although there are quite some techniques around for RIA kind of applications, none of them is supporting Rich functionality for Document Editing and with Rich i mean RICH. Not only you can edit a document, the document is of course instantiated from a template coming from our central Repository. It can also be setup in a way that users can only edit in certain area`s, can use restricted fonts, colors etc. and dynamically building text can be selected or deselected, etc……..
Read on to find screen dumps
Continue reading Papyrus EYE Enables Rich Document-centric Applications with Identical Experience across Browser and Fat Client
By Ben, on August 9th, 2008
One of my current projects is responsible for delivering a library of functions that are used by several applications being built and maintained at our customer. One of those functions in particular is quite central to the operation of all the applications that use out library and is responsible for collecting, transforming and combining data from many different sources (essentially it is an orchestrating function). This function has a classical codebase, in the sense that the codebase started out being much smaller than it is now and with fewer tasks but has since grown. The library function is being developed continuously and will be expected to meet more and more requirements as more and more data must be collected and correlated. The problem, as you can imagine, is that the codebase is becoming unmanageable as more and more code goes into it. So we are faced with the question: how can we refactor the existing codebase to improve manageability?
As mentioned before the function in question is essentially an orchestrator, collecting data from several locations and combining these different data into one package. The collection of data is not random, however: some requests depend on the results of others, creating a natural partitioning of the function’s code into tasks with an internal ordering. Of course, this sounds like a classical orchestration setup and the first suggestion might be to use an orchestration tool like a BPEL engine. However, integrating a BPEL engine into the library seems like overkill given the current size and complexity of the function (and doesn’t fit well with the rest of the library). So instead my project is going to attempt an intermediate solution between the current pile-of-code architecture and a full orchestration tool: the Life Cycle Pattern.
Continue reading The Life Cycle Pattern
By Ben, on August 6th, 2008
Does the name dihydromonoxide sound in any way familiar to you? It should (really, it should). Try googling it (here, I’ll make it easy for you). If and when you do google it, you will be informed by all sorts of sites of the various properties and dangers of this chemical compound. This one, for instance, covers all the dangers of dihydromonoxide (or DHMO) in great and completely accurate detail.
Of course dihydromonoxide and the many warnings against it are all based on a clever use of words. Seen in that light dihydromonoxide is a wonderful example of something I was taught by a professor of mine at university (and reminded of a couple of times today): Shakespeare may have prattled on about roses by any other name, but in reality notation is absolutely everything in our business.
Continue reading Dihydromonoxide: what’s in a name?
By Ben, on August 5th, 2008
Author’s note: Unlike my other posts so far, this is not going to be a technical article. So you can skip it if you like. 
Or if you are an Apple fan with a weak heart….
For some reason, half the world seems to have gone mad over Apple products. Ever since Apple introduced the idea of gimmicky design features (ranging from wheel-controlled MP3 players to processor-powered toilet seats), Apple seems to be the be-all and end-all of consumer electronics. And I don’t get it. Perhaps somebody could explain… ?
Apple computers has always been a company on the leading edge of Human Computer Interaction. Back in the 1980′s they were among the first computer builders to start putting the lessons from Xerox PARC into practice. They were one of the first companies to use Engelbart‘s mouse commercially, being the second to combine it commercially with a GUI in the Apple LISA (the first being Xerox with its Star system). This line of development continued with the Apple Macintosh which quickly grabbed the high-end graphical market in the second half of the 1980′s while IBM-compatible machines dominated the non-graphical business market. This split lasted until Microsoft Windows popularized the GUI on the lower-end IBM-compatible hardware and opened the door for graphical applications on that platform. At that moment the market mechanism started to kill off Apple’s position: Apple machines moved from being dedicated graphical heavyweights to being overpriced nothing-special computers.
Continue reading MacCrook
|
|
