Diomidis Spinellis writes in the recent IEEE Software Journal an article "Open Source and Professional Advancement" which I can highly recommend to all students.
In short, his argument is, that the best way (but for sure not an easy one) to improve skills in software engineering and programming is to try to participate in (prestigeous) Open Source projects. I personally can only support this point of view. First of all, students can learn the dynamic of a project of considerable size, learn how communication is done, how sourcecode is managed, how releases are planned, how bugs are tracked and so on. And this on a "real scale".
When they go deeper, they have to learn to read sourcecode from other developers, which is an invaluable skill. They can learn how very good developers program by seeing the results, but also how certain bad designs can affect the quality of code, and they can try to help fixing that.
Besides these skills, working in an Open Source project can be a very satisfying experience. Particularly considering the fact, that the work done for the project (if it is good) is actually used for probably thousands of production systems and not "dumped" like the typical projects during study.
Of course I do not want to give the impression that it is kind of an easy route to just jump in as rookie and develop some extensions for Tomcat. It is not fast money. It is not. Most probably it will taks considerable time to understand prominent OS projects from the user point of view, not to speak of the developers point of view. Even so, the first efforts will probably be rejected by the community, probably it is very hard to understand the sources of the project.
So we speak of a procedure that has a time frame of years, not months and is only recommended for the talented and spirited student deeply interested in producing first-class software. But for those it is probably the best way to get insights and skills that can be hardly acquired otherwise.
However, even if eventually the motivation is not strong enough to actually contribute code, it pays off to go the step beyond beeing "simple user" and going in-depth of a project. The learning effect is still significant and also other ways of contribution are typically highly appreciated (help in forum/wiki, writing tutorials, ...).
Tuesday, October 03, 2006
[Misc] Learning from and with Open Source Projects
Posted by
Alexander Schatten
at
Tuesday, October 03, 2006
2
comments
Categories: Miscellaneous
BLOG Design Issues
At the moment, we have some issues with the design templates of our BLOG. We experimented with new design to enhance readability for the reader, but currently the result is not as desired.
We are working on this issue. Please be patient at the moment and stay tuned and continue reading and commenting our articles!
Posted by
Alexander Schatten
at
Tuesday, October 03, 2006
0
comments
Categories: About
Wednesday, September 27, 2006
[Process] Measuring "Agility"
"Agile Manifesto" Agile Trends in Software Engineering
The "Agile Manifesto", eXtreme Programming (Kent Beck), Scrum... Agile methods of software development can be found everywhere these days. And there are good reasons for this trend. Traditional software engineering apparently found it's limits. Particularly in software projects dealing with fast changing requirements, fast changing technologies and unclear user-demands.
Measuring Agility
Talking about agile processes I have the impression, that there is yet no propoer definition of what agility actually is. Particularly not a definition that could be seen as a foundation for a quantitative measurement of agility. Or a measurement if a (software) team is able to react agile on changing situations. So following internal discussions I want to propose an idea on how we could treat this question.
This figure should illustrate the idea (please click on the figure to enlarge it):
- The x-axis shows the timeline
- The y-axis actually shows two things: on the left (according to the red line) the overall increase in "business value" e.g., of a Software product (number of features, ...) the right side indicates the ideal level of maximum fulfilment of feature request at a given time (iteration time). The "100%" shift upwards, as from iteration to iteration higher business value is demanded; or expressed otherwise: as the complexity of the environment is continually increasing (right scale) the business value of a static application is continuously decreasing
- As the overall complexity increases, the "100% line" gets higher with time
- However, this means, that the actual quality (according to the business value) of the product decreases over time as the scales shift. This could be measured as d (deterioration).
- The time needed between two iterations is r (retention) time
- Then total gain in quality (absolute according to the left scale) between two iterations is indicated by i (improvement)
A system is more agile if
- r : d is small (the faster deterioration d takes place the shorter r should become)
- i1...in in relative terms (right axis) stays constant, meaning the relative quality over iteration stays constant (or gets better)
- (d+i) --> 0; ideally the steps between iterations are low, and a continuous improvement is observed
Posted by
Alexander Schatten
at
Wednesday, September 27, 2006
4
comments
Categories: Processes
Thursday, September 21, 2006
[Arch] Web 2.0 Patterns and the lacking Separation between Producers and Consumers
"Web 2.0" Patterns
This article tries to define what these "new Web 2.0" applications distinguish from the Web-applications we have seen the years before. The article covers the "Web as Platform", new concepts of web-services and applications as well as the social phenomenons emerging around these new services.
Besides the fact, that new technologies like Ajax, Flash, OpenLaszlo, Rails and the like push the development of new and rich Web-Interfaces (which is an SE topic itself), the most interesting aspect for me at the moment, is the discussion of the "End of the Software Release Cycle". Particularly the second assumption: "Users must be treated as co-developers" is (from my point of view) the most relevant and stunning new phenomenon in the new "Web 2.0" and "E-Commerce" concepts.
In and Out
- reporting bugs
- helping new users in the mailing list
- providing information in the project Wiki
- writing tutorials
- Amazon partly builds upon the workforce of users commenting books, CDs and so on: these comments are actually for free (from the perspective of Amazon), and the customers are providing work that was until now paid for.
- Flickr builds also upon the idea, that users tag pictures, hence they provide the necessary information for the company to build efficient categories and search functionality.
- Even if customers do not provide active work, their sheer activity on the website is used: for example Amazon evaluates the click streams and buying behaviour and creates additional functionality for their website: "What do customers ultimately buy after viewing this item?"
- Google evaluates Websites and searches from users; analyses the work web-authors do, for example by making references to other pages. This information is a core necessity for their page-ranking algorithm. The data comes from customers.
- Google provides a fundamental Maps framework; in the future the rich Map-applications will be provided by "customers"
Similar concepts can be seen in online gaming: "monolythic" games will be, in my opinion, replaced by platforms where users very actively will contribute their designed landscapes, characters, weapons, and so on.
This trend will pose significant changes on companies and developers who still stick to old software engineering paradigms.
This will more and more effect the relationship between customers and producers, the way sotware is developed and eventually the relationship between companies and their employees.
Posted by
Alexander Schatten
at
Thursday, September 21, 2006
3
comments
Categories: Architecture, Enterprise Integration, Processes, Web Development
Monday, September 18, 2006
[Tech] BPEL with User Interaction
BPEL (Business Process Execution Language) is used for service orchestration in Service Oriented Architectures. The current standard of BPEL is designed to automate business processes based on Web Services. However traditional business processes often requires human interactions which is currently not supported by the BPEL standard.
For this purpose, IBM and SAP developed BPEL4People. This extension is defined in a way that is layered on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed. The most important new constructs in this extension are:
- Generic Human Roles define what a person/group can do in a specific process activity.
- People Links are used to represent the different groups of people who participate in the execution of the process (e.g. link to LDAP)
- People activity is a basic activity, which is not implemented by a piece of software, but realized by an action performed by a human being (e.g display an User Interface where the user can do something).
Posted by
Markus Demolsky
at
Monday, September 18, 2006
0
comments
Categories: Enterprise Integration, Technology
Wednesday, September 13, 2006
[Tech] Derby's next round
Since the "Open Source" move from IBMs Cloudescape to Apache Derby, there were quite some discussions about which would be the Java Database of choice. Currently mainly two systems are prominent and in discussion: hsqldb and Derby.Java Databases?
- Databases like Derby are meanwhile very mature and can compete with non-Java systems
- Java-based databases integrate smoothlessly into Java projects; also using O/R mapping tools like Castor or Hibernate: In this case, the complete application including persistance stack is in Java.
- Different operation modes (Server, Embedded)
- In the embedded mode, no network communication takes place, with respective consequences for performance and security (no connection to database from outside the application is possible)
- No need to install or configure the database at the customer (in embedded mode)!
Performance
A second (and third look) shows: hsqldb uses (per default)
- in-memory tables: all data is kept in memory
- might be used embedded, hence no network overhead takes place
- has enabled huge write delay, meaning, that even committed transactions are not persisted at the moment, but up to one minute later!
- hsqldb has no proper implementation of the database ACID criteria, e.g., allows dirty read
Additionally, the access frameworks have to be taken into consideration: nowadays developers hardly use JDBC directly, but use technologies like iBatis, Hibernate or Castor, and this again has significant impact on performace (using Caches or not, ...).
News in Derby 10.1.3.1
News in Derby 10.2
The upcoming Version 10.2. will have some significant improvements (from the Derby Wiki):
- Scrollable Updatable Result Sets
- JDBC4
- Grant/Revoke
- Online Backup
- Stronger Network Authentication
This release should be out yet in September, so stay tuned!
References
To get information about Apache Derby, read the Website and the Wiki (!) for recent activities.
Check out the very interesting BLOG entry: David van Couvering's Blog: About ACIDity and Java Databases.
Posted by
Alexander Schatten
at
Wednesday, September 13, 2006
3
comments
Categories: Java, Open Source, Persistence, Technology
Sunday, September 03, 2006
[Misc] Does it matter to know more than one language?
This weekend I've read two interesting articles. The first one from Joel Spolsky with the title “Language Wars” discuss the usefulness of the ever raging discussions between software developers about the “right” programming language. Besides that he admits that this kind of discussion is definitely fun, but if you want to develop a production quality system the decision depends on the maturity of the language (and tools) and the skills of your team.
The second article is from Luke Plant titled “Why learning Haskell/Python makes you a worse programmer”. He describes his experience of using concepts of not so common languages at daily work. His conclusion is, that, not surprisingly, it comes to very bad results if you use as example sophisticated functional language idioms inside code which does not support the underlying concepts.
In the real world, knowing a lot of languages gives you definite advantage. But, and this is my question, is this so clear for programming languages?
Learning a language needs a lot of time and most of all, it needs practice. Most professional software developers only use one (or at most two) languages for their daily work and they speak them fluently (that's why they are called “profession” ;-). In our days, this are Java and sometimes C#, a decade ago this was mostly C/C++. The tides change so it is out of discussion that a developer learns more than one language in his life (at least I know one who knows someone who knows Fortran). Today, there are a lot new languages on the surface, some really new, such as Ruby, some rediscovered, such as Erlang or some which were around us but nobody noticed them (Python). There are also a lot of mere academic languages, such as the upcoming Fortress and Scala. And there are all the rumours about Domain Specific Languages.
New languages may have features you want to use, which are so sophisticated and elegant that you never want to see braces, but makes it sense for your daily work, and the quality of it, to learn one of them? There a to different views to this: for geeks and developers, it makes absolute sense to to this, learn new concepts, write little and shiny programs and have some fun to explain your knowledge to the “unliterated”. But for your project and your company, it can make no sense at all, it can, as Luke Plant describes it, be a waste of time. As example, Java and C# have are easy to learn languages but to use them in a productive and professional way needs a lot of time, besides nobody will ever know all features of their frameworks. So for your daily work, it may be the best to practice what you already know, develop useful idioms and patterns and read about knew concepts in your language, such as Generics or LINQ, and learn to use them to build readable, testable and stable code. It may be possible that you are someone who is skilled enough to speak more languages fluently and you can practice, but most of us developers are not (mostly because of practice).
For me personal, it makes sense to learn other languages because they can teach you new ideas and concepts and it is at least possible to practice if your take part in some open source projects or build small tools for your personal use. On the other hand, at work you need every bit of knowledge you have to develop a good piece of software, so every experiment can be harmful.
Posted by
Anonymous
at
Sunday, September 03, 2006
3
comments
Categories: Miscellaneous
Tuesday, August 29, 2006
[Tech] Spring on the Client
- Mature command framework
- Data Binding and Validation Framework
- Multiple Window Support
- Factories for common GUI controls complying GUI standards (Wizards, Dialogs,...)
Posted by
Markus Demolsky
at
Tuesday, August 29, 2006
0
comments
Categories: Java, Open Source, Technology
[Pub] State of the Art in Java Enterprise Web Application Development
With the rise of object-oriented thinking, frameworks became more popular than never before. A framework is an approach of software reuse and enables developers to establish software systems on an abstract layer. This diploma thesis focuses on the layered architecture where each layer has a predefined task which can be implemented together with a provided framework. This diploma thesis covers the following key points:
- Introduction to Software Architecture
- Relevant patterns for J2EE, like MVC, DAO, ORM, Lazy Load or Dependency Injection
- Architecture of object oriented frameworks
- Technologies: Hibernate, Spring, Spring Web Flow, Struts, JSF and OpenLaszlo
Posted by
Markus Demolsky
at
Tuesday, August 29, 2006
0
comments
Categories: Java, Publication, Web Development
Sunday, August 27, 2006
[Pub] Probing and Monitoring of WSBPEL Processes with Web Services
- The BPEL standard provides no auditing capabilities
- In BPEL engines, auditing is (if available at all) implemented in different ways
- Auditing over multiple BPEL engines (e.g., integrating various partners) is hardly feasible
Read more about our ideas in our paper.
Posted by
Alexander Schatten
at
Sunday, August 27, 2006
0
comments
Categories: Conference, Enterprise Integration, Processes, Publication