Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by jcn at 12:43 on Friday 15 December    Add 'Strategic Design' site to delicious  Add 'Strategic Design' site to technorati  Add 'Strategic Design' site to digg  Add 'Strategic Design' site to dzone

Eric Evans gaf een presentatie over het gebruik van Domain Driven Development. Hij deed dit aan de hand van een case over een vervoersbedrijf, dat via containerschepen goederen aan klanten leverde.
Binnen zo’n project komt het vaak voor dat hetzelfde probleem op verschillende manieren gemodelleerd wordt door verschillende teams. Dit komt doordat een systeem vaak een hele reeks requirements heeft waarbij het voor het ene requirements beter is om systeem op manier A te modelleren en voor een ander requirements op manier B.

Vervolgens behandelde hij een methode om het ‘core domain’ van een systeem te bepalen. Het systeem wordt daarbij opgesplitst in drie verschillende domeinen:

  • generic subdomains: dit zijn dingen die generiek en daardoor gemakkelijk via off the shelf producten te krijgen zijn.
  • supporting subdomains: dingen die wel nodig zijn, maar niet direct van strategisch belang zijn voor een bedrijf. Gedeeltes die hier onder vallen, zijn kandidaten voor outsourcing.
  • core domain: dit is het gedeelte van het systeem wat van strategisch belang is. Dit zijn dingen die het zijn om inhouse te maken. In de case gebruikte hij het voorbeeld dat het voor het bedrijf van
  • strategisch belang was dat klanten zo snel moeilijk hun goederen geleverd kregen. In zo’n geval heeft het zin om zelf inhouse het routing systeem te ontwerpen (ipv. het te outsourcen of te kopen).

Posted by Eric Gunnewegh at 8:53 on Thursday 12 October    Add 'AJAX Design Strategies' site to delicious  Add 'AJAX Design Strategies' site to technorati  Add 'AJAX Design Strategies' site to digg  Add 'AJAX Design Strategies' site to dzone

Web applications have entered a new era driven by web site goals such as fast response to user actions and user collaboration in creating and sharing web site content. The popular term attributed to these highly responsive and often collaborative sites is Web 2.0.

This article is about the primary technique in use today for making Web 2.0 sites highly responsive: Asynchronous JavaScript and XML (AJAX).

Posted by Barend Garvelink at 10:00 on Thursday 20 July    Add 'Design 101 for developers' site to delicious  Add 'Design 101 for developers' site to technorati  Add 'Design 101 for developers' site to digg  Add 'Design 101 for developers' site to dzone

In Adobe’s nieuwsbrief staat deze maand een artikeltje getiteld Design 101 for developers, met daarin een aantal tips om je Rich Internet Application prettig te maken voor je eindgebruikers. Veel van wat erin staat valt wat mij betreft onder “gezond verstand”, maar het is best een nuttig rijtje adviezen om nog eens bij stil te staan.

Hier is de link naar Design 101 for developers.

Posted by Hans-Jürgen Jacobs at 8:55 on Monday 12 June    Add 'Great Mistakes in Technical Leadership' site to delicious  Add 'Great Mistakes in Technical Leadership' site to technorati  Add 'Great Mistakes in Technical Leadership' site to digg  Add 'Great Mistakes in Technical Leadership' site to dzone

Perhaps the most difficult job to do on any software development project is that of Technical Lead. The Technical Lead has overall responsibility for all technical aspects of the project – design, code, technology selection, work assignment, scheduling and architecture are all within his purview. Positioned right at the border of the technical and managerial, they are the proverbial “meat in the sandwich.” This means that they have to be able to speak two languages – the high-level language of the project manager to whom they report, and the low-level technical language of their team. In effect, they’re the translator between the two dialects.

Read more here.

Posted by Ruud Steeghs at 14:52 on Saturday 28 January    Add 'J2EE design decisions — Learn how to discern which design patterns and frameworks would work best for your enterprise applications' site to delicious  Add 'J2EE design decisions — Learn how to discern which design patterns and frameworks would work best for your enterprise applications' site to technorati  Add 'J2EE design decisions — Learn how to discern which design patterns and frameworks would work best for your enterprise applications' site to digg  Add 'J2EE design decisions — Learn how to discern which design patterns and frameworks would work best for your enterprise applications' site to dzone

In this article, an excerpt from POJOs in Action (Manning Publications, January 2006), Chris Richardson presents five questions developers must ask themselves when designing enterprise applications

If we blindly used POJOs (plain-old Java objects) and lightweight frameworks, we would be repeating the mistake the enterprise Java community made with EJB (Enterprise JavaBeans). Every technology has both strengths and weaknesses, and it’s important to know how to choose the most appropriate one for a given situation.

This book is about implementing enterprise applications using design patterns and lightweight frameworks. To enable you to use them effectively in your application, it provides a decision-making framework that consists of five key questions that must be answered when designing an application or implementing the business logic for an individual use-case. By consciously addressing each of these design issues and understanding the consequences of your decisions, you will vastly improve the quality of your application.

In this article you will get an overview of those five design decisions. I briefly describe each design decision’s options as well as its respective benefits and drawbacks.

Posted by Hans-Jürgen Jacobs at 11:35 on Wednesday 4 January    Add 'Java API Design Guidelines' site to delicious  Add 'Java API Design Guidelines' site to technorati  Add 'Java API Design Guidelines' site to digg  Add 'Java API Design Guidelines' site to dzone

There are tons of books and articles about how to design and write good Java code, but surprisingly little about the specific topic of API design. Here’s a summary of what Eamonn McManus
learnt on the subject from various sources and his own experience. [artima.com]

Posted by Hans-Jürgen Jacobs at 17:27 on Wednesday 7 September    Add 'An Introduction to Antipatterns in Java Applications' site to delicious  Add 'An Introduction to Antipatterns in Java Applications' site to technorati  Add 'An Introduction to Antipatterns in Java Applications' site to digg  Add 'An Introduction to Antipatterns in Java Applications' site to dzone

Just as design patterns provide a way to communicate concisely about desired software practices, antipatterns provide the equivalent advantages for communicating undesirable practices—and here’s a set of common antipatterns to get you started. [devx.com]

Posted by Hans-Jürgen Jacobs at 15:32 on Tuesday 31 May    Add 'Erich Gamma on Flexibility and Reuse' site to delicious  Add 'Erich Gamma on Flexibility and Reuse' site to technorati  Add 'Erich Gamma on Flexibility and Reuse' site to digg  Add 'Erich Gamma on Flexibility and Reuse' site to dzone

Developers are often faced with decisions about how much flexibility to design into their software. In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about the attitude he believes developers should adopt towards flexibility and reuse. [artima.com]

Posted by Hans-Jürgen Jacobs at 10:54 on Friday 21 January    Add 'Design by Wiki' site to delicious  Add 'Design by Wiki' site to technorati  Add 'Design by Wiki' site to digg  Add 'Design by Wiki' site to dzone

Is your project drowning in a sea of useless, out-of-date, and irrelevant documentation? Or is your project foundering with no map whatsoever? Before you shell out time and money for a proprietary package, consider that a humble wiki may solve most of your woes. Jason Briggs explains how his team uses MoinMoin to track its project documentation–and diagrams. [onlamp.com]

Posted by jcn at 13:12 on Wednesday 19 January    Add 'Architectural manifesto: Designing software architectures, Part 1' site to delicious  Add 'Architectural manifesto: Designing software architectures, Part 1' site to technorati  Add 'Architectural manifesto: Designing software architectures, Part 1' site to digg  Add 'Architectural manifesto: Designing software architectures, Part 1' site to dzone

Poorly designed architecture affects an application throughout its lifetime and can result in inestimable costs. Given this fact, it is surprising to see that the software architect’s job is so often overlooked. Many businesses do not have software architects at all or they assign the role of software architect to someone in the shop; such as a software designer who might not have the experience to do the job correctly.

In the worst-case (but not at all uncommon) scenario, the so-called software architect is also working on other tasks integral to the project. In this case, the overburdened individual — even if he or she is a trained software architect — becomes little more than a figurehead. Design process and documentation are quickly abandoned, with predictably poor results.

To remedy this, I’ll devote the next few columns to discussing the importance of the software architect in the application development process. I’ll start this month with an overview of the architecture process in an example design project. Next month I’ll go more in depth by looking at how the architect guides the process from start to finish. [www-106.ibm.com/developerworks]


© 2019 Java Competence Network. All Rights Reserved.