Research and Destroy

Sure…

Via FAIL Blog

(German) parody on… on what exactly? Battlestar Galactica?

… from the fettgaumen.de blog: To do something against there continuous, unresponsible, morbid, excessive, mind-blowing consumption of fat here is something which might become their salvation:

:-)

Seems there crashed some Trading Birds…

Finally, TradingBird goes GA!

You guys ask for features? Here are my $ 0.02:

• You offer a ranking of diversified portfolios which have to comply with certain rules of engagement. Now why not offer diversified rankings for assets or orders, too? If a user is only interested in items which comply to this rules of the diversified ranking, it would be nice to have the ability to select the buys, sells and holdings which associate with these portfolios.
• Already mentioned by others, without this feature the trading form is most inconveniently: When selling assets from my depot, the number of pieces I own should be transfered to the sell-from.
• Minor issue: If I’m not mistaken, the default sort in a lot of views like my depot positions is by asset name, descending. Descending means Z-A… This should be changed to ascending sort order I guess.
• As you can see in this image, when I’m logged in and go to the depot rankings of my contacts, the page title reads “startMyContactsRankings.jsp#BROWSER_TITLE“. Guess someone forgot to update a resource bundle…
• A minor typo on the next page, transactions of my contacts, the browser title reads: “Wertpapier-Transaktionen bet Tradingbird [...]”

So far my current suggestions.

There are so many Books about more or less ingenious design patterns, engineering guidelines, modularization, framework usage etc. no one could ever afford the time to actually read one of them. The main point in all of these efforts is widely the same:

I don’t want to do more work than I have to.

Which is, in fact, the principle of all technology, up to the point where having spent efforts in technology finally frees us from the efforts of the task itself, leaving us just with the efforts of fixing that technology when (if would be nice here, but is inappropriate) it breaks and the effort of finding something meaningful to do. It unfortunately implies “If I can drive a car with three wheels, why should I bother buying the fourth?”

So why the heck can’t I just…

I mean, you get a task. Say like “Write an online application”. What you want to do is get rid of it forever. What your company wants is to get rid of it soon.

So they order you to get it done as soon as possible and you will be spending time on it forever. Face the fact.
And the first solution that would come to your mind would be: “OK, if I do this as simple as possible, I won’t be doing complex errors and be done with it quickly.” Which is a correct assumption. For one, finite Task.

This is, where multiplicity comes into play. You won’t be doing one Task in one context. You won’t be done with it, ever, either. And the first one coming after you will most probably have to do it again in a slightly different fashion. And there is a word for multiplied simplicity: Chaos.

There is a certain amount of complexity that a System will always have, defined at least by the complexity of the tasks it has to perform. There is no way to eliminate this complexity, not even with Object orientation, 4GL and UML. So what happens if you seem to have eliminated complexity is that you actually shifted it somewhere else. Which can be a good thing, once that “elsewhere” is in the domain of your customer’s organization and they can live with it. Or inside some framework voodoo.

Calling things differently or avoiding to name them at all does not eliminate complexity either. It just takes away any possibility to handle them. If your application does not have explicit Tiers (Yay! We have a one-tier application! That is only a quarter of what a 4-Tier application would cost us!) it nonetheless has implicit ones, and usually more than you would imagine. If your application does not employ a model (saved efforts incoming!) it will have an implicit model nonetheless, and even better, it will have several models describing the same thing, once that thing is used in two contexts!

We have a developer here that spent much time painting tables with fields to find implicit models for which no classes exist.

So why bother with architecture, modularization or reuse at all? I mean, even if your system starts with minimum complexity, future evolution will soon drive it into entropy anyway! And yes, this is an effect that can not be avoided by any means we here possess. Any concept of reuse requires overhead, abstraction and configurability which makes the would-be reusable component even more complex. Any concept of modularization requires much work on how these modules interact, are composed, packaged, defined and you have to do much work just finding out where to put your stuff.

Fun, isn’t it? We actually add more complexity to an already complex system, to be able to view it in a more simple way. Isn’t that ridiculous? No.

What we can do, is shift complexity away from the evolving spots. We can move it out of the multiplying part of the system, which is usually defined by the features. Since complexity is there, and cannot be done away with, we have to face it somewhere and make sure that it is faced only once. So there are complex components, difficult to understand, cryptic, like many components of software tend to become when left alone for a couple of years, but we have them in their own biotope of complexity, and most important of all, we have their complexities separated, able to be handled one at a time by different people.

It is not the aim of modules to enable old, smelly code of old to work forever, but to have clear places to cut once parts of that code fall to the teeth of time and have to be replaced. Furthermore, we have Modules to enable composition of more than one product (or variation thereof, like a staging installation) while using the same, tested implementation with a different configuration. Featuresets and other terms known to multiply are allowed their own module to keep the multiplying stuff out of their dependencies. This ist costly, but it costs less than multiplying everything in every code.

We do not produce future code that handles all possibilities of future extendsions, but we provide valid rules for extending the system, at defined places, with defined terms and common basic functionality. So then the future code may multiply and change as much as it wants, as long as we are able to handle these multiplying components at all, our basic system remains stable, in fact, it gets even more stable with each new component that uses it, and it actually stays… simple.

So everytime I drop a design abstraction for the sake of simplicity,  I should take a clear look where it actually went, because I can be sure it will bite me some time.

When I read a book about object orientation, the first argument for OO is “Encourages reuse of code”. No. It doesn’t. It enables you to do reusable components, but these do not besome reusable by just writing “Class” somewhere atop your old code.

Some nice parodies on the MacBook Air Commercial…

Did you ever get scared about modern Software being all too intelligent, that it would finally take control and such? Don’t be.

Really… after all that architecture nonsense and fruitless “platform” development (like in “fill the svn with a crapload of thingies which are ignored and reimplemented anyway”), the old question: “Yeah! But is it ART???”. How could web application development possibly benefit froum our efforts?

Today, I came across my first new component that did, for a change, require no big deal of “platform” implementation. In the unyielding hope, that this at one far day might become the rule and not the exception, I’d like to shed some light on the details.

• I started with the query. That is a good way to start, one gets a good hold on what to expect and what to pay for. Since we are doing a rewrite of existing software, I held my breath and dove deep into the existing PHP. To find a previous implementation in the action code that pretty much resembled a query along with some decision code and a “routine” (Piece of code set apart with blank lines and actually sporting a comment) to determine bar width for some kind of bar diagram – fine.
• The query wasn’t too complicated, basically a PageableListQuery, for which a base implementation exists. In my concrete query, I put in interfaces for Cacheability and the data provider datasource where it should be executed.
• Once the query was there and I had determined the query parameters needed, I realized that the return type of that query actually missed in our Object model. Since our BOs do not have any Dependencies, I unscroupulously added a new class asking questions later.
• The class stayed small, the table actually looks full of data but in reality it only has a few colums plus it is sortable.
• Suppressing the urge to do something entirely different first, I introduced a pretty stark junit test case that asserts at least the query string that goes to our data provider and checks if it is possible to get a result at all. Of course, the result list had zero elements and some Exception hit the wall next to my head.
• There was a new BO Type, so I had to write a Mapping for it. Since I am the first and only person to request this BO type, my Mapping goes to the class annotation as default mapping, go me! And since it is an unspectacular list mapping, I even get to retain the GenericListMapping for the iteration part and only have to implement the single object part, which is nice because this is very unlikely to produce strange errors. Mappings could be far more generic and self-contained, but our data provider has a rather odd object design and it is better understandeable to have some repeated code than some cryptic extension code to a generic mapping where no one knows how it works.
• With the generic list mapping annotated to the query class and the item mapping to the BOM class, the platform knows enough to get me datah! One day soon I’ll make GenericListMapping default for all ListQueries, but that’s not so easy.
• Tried the test case again. Yay! One field was not mapped correctly, but the result graph was o.k. It is good to know that a query executes correctly without having to deploy the application to JBoss to find out.
• Added some meat to the test case, but it is not wise to make the data content tests too sharp, it is not our Job to ensure data quality of our data provider which more often than enough irritates our tests. A result list with more than one entry and the first entry object with some correctly mapped fields in all graph objects was enough.
• Started Struts action implementation. Since the table does not have any complicated decision code and no data rearrangement voodoo either, I didn’t have to add much to the class. There is a default implementation for actions that display a List of BOs called PageableListAction which I could extend, all I had to do is add the action parameters, a method that creates the query and passes the action parameters to it (if that does not come from the configuration) and a little method to calculate the bar width. Since this one does not produce an array of widths but only one result per BO, it shrank down to one line.
• When looking into the navigation.xml config I saw that The Ralph of God had already left His traces. Normally, I would have to add a menu point in the main Navigation and four tab navigation entries there, pwith the possibility to configure default parameters or query implementation.
• in the struts.xml, someone had done similar, but I still had to add result entries since the JSP (can’t blame them, the pages don’t exist yet, not everyone is adept at precognitive software engineering) since we do no magick in the struts config, I can forget about that file from now on. Actually, I do so from time to time, the PostIt at my monitor labeled “Remember that there is a struts.xml” surely helps.
• Speaking of JSPs, they were the worst part that time. Usually, there is a premade file from the HTML Ubergurus which dwell on the surface that I can cut and paste, put some <xx:iterator> and <xx:text> here and there and be done with it, but these were a little strained with other, more important stuff so we had to extract from the old system. Which is what I did, the templates of the old system are well separated from the “action” code (that is a good thing) and it looked easy enough.
• There are 2 JSPs now, one for the page and one for the component. It is the first and presumably only usage of that component, but concrete implementations of entire pages always attract later changes that fry the recyclability. The component jsp is called from the page JSP by <xx:action> and that’s it, since I do not require any additional parameters yet that I would otherwise put in here.
• Added standard component JSPs for taglib include, header and footer to the page and and tab navigation along with a page count/progression control to the component JSP, whatever crash should occur on that page, it will at least look nice from now on.
• There should be a test case for that one-line bar-width calc method, I know. I promise, there will be some time in the future.
• Smoke test. Bäm. Some THING emerged. From now on, bugfixing.

If you’re not familiar with FAD, then you’ve been missing out. Essentially, FAD is a fundamental paradigm shift over the “traditional” and “neo” ways of building software. Not only does it surpass every other software development methodology out there, it solves every problem there is to building software. And then some.

The FAD Manifesto

I. Front Ahead Design
The essence of FAD is conveyed directly in its name: design your front-end/user-interface first, ahead of everything else. The customer could care less what’s behind the scenes, so long as it looks good and does what it’s supposed to. Deliver a working front-end first and then Do What It Takes to fill in the functionality gaps.

II. Do What It Takes
Other methodologies are great at delivering excuses. How many times have you heard (or have been told) “we can’t do that here because it could throw off the whole design?” In FAD, you just do it (that would have been the bullet point, but Nike has it trademarked). To get it done, you Do What It Takes. Your customer will love you.

III. Code Light, Not “Right”
A traditional methodology calls a complex framework with layer after layer of objects. In those ways, adding a simple value to a form can be a monumental task, requiring it to be added to every single layer. Does that sound right? Proponents of the other methodologies will tell you it is, but what about your customer? With FAD, you just Do What It Takes to add the functionality to your interface. No more.

IV. “Throw Away” Diagrams
Think of all the Visio diagrams you’ve drawn over the years. Sequence diagrams, context diagrams, flow charts, and so on. Was that really productive? Did your customer ever see any of those? Were those diagrams even relevant after the system was finally developed? Didn’t think so.

In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work. And there is no formal modeling language to battle with: just Do What It Takes to draw and explain your design to other developers.

V. Life Is Short (a.k.a. Patchwork)
The average software system has a life expectancy of seven years. No matter how “properly” the system is designed from the start, within the first year of its life, maintenance programmers unfamiliar with the complex architecture (and having no help from out-of-date documentation) will turn the system into a complete mess with bug fixes and change requests.

In FAD, this isn’t even a concern. We know the short life span of a system and develop every feature (from the interface) as a patch. Maintenance programmers can come in and Do What It Takes to add their patches. In FAD, we don’t even try to stop the aging process. We encourage it.

VI. Learn To Deal
Many other methodologies focus on delivering “quality” (as in “bug free”) software. And guess what: they fail. Miserably. No matter how hard you try, software will have bugs. In FAD, we just learn to deal with it, and we encourage the client to do the same. So what if the application crashes when you click that button that way? Don’t click the button that way, and learn to deal!

VII. Be Environmentally Conservative
In the real world, there’s only one environment: it’s called The Real World. So why do some methodologies invent these counter-intuitive, bizarro environments called “QA” and “UAT”? Do architecture firms construct an entire house before building an addition on yours, just so they can “test” their building skills? Of course not, and neither should software developers. In FAD, there’s only one software environment: Production. Anything else is pollution.

FAD Application Design

NOTE: First and foremost, understand that the FADAD is merely the preferred method of building applications. Because in FAD, we do what it takes, a lesser or more in depth approach can be used as needed.

Many of the tenets of Front Ahead Design are based on the failings of other methodologies. FADAD is no different, and draws some of its key facets from the archaic Model-View-Controller architecture. In MVC, there are three different components: the Model (the data), the View (the UI), and the Control (everything else).

If you think about it, two of MVC’s components are nothing but dead weight. All anyone – including the client – really cares about when all things are said and done is the View. Therefore, in FADAD, our guiding architecture model is simply called “V”:

The H/YPE Framework: The FAD Developer’s Best Friend

If there’s one thing that’s frustrated just about every developer out there, it’s “untouchable” library code that almost does what you need it to, but not quite. For FAD developers who chose to use the H/YPE framework, this is not a problem.

Unlike the stodgy libraries of yesteryear, H/YPE is not a “compiled” library. It’s a set of cross-language codefiles that can be copied to any application, and is designed to “live” with that application for life. Don’t like that 48 plus 92 is not 4892? No problem! Just edit MathHelper. Here’s a small subset of what comes in H/YPE:

• HYPE.StringHelper – all sorts of functions like IsEqual, AreEqual, Add, Subtract, Join, DoubleJoin, Encrypt, and Decrypt
• HYPE.VHelper.HTML – the ultimate HTML library including functions like WrapInCENTER, UnHTML, ToHTML, and ScriptBlock
• HYPE.Audio – everything you’d ever want to add audio, including Beep and BeepMore

But Wait, There’s More: Certification!

No, I don’t mean to sound like our good friend Ron Popeil, but before wrapping things up here, I wanted to tell you about the latest excitement in the world of Front-Ahead Design: certification!

Just last week at the International FAD Conference in Azerbaijan, I joined several other FAD leaders to formally announce the first official Front-Ahead Design certification program: the Fadstronaut certificate. Why Fadstronaut? Because we felt that the astronaut was the best analogy for the challenges and difficulties that FAD software developers face each day.

Becoming a Certified Fadstronaut is easy, but not too easy. All you need is one year (1,000 hours) of verifiable FAD development experience, and you’ll be eligible to sit for the Fadstronaut certification exam. Score in the 50th percentile, and you’ve earned the designation Certified Fadstronaut!

I hope that gives you all a good idea of what FAD is all about. Believe me, there’s a whole world more of FAD out there. That said, I hope to see some of you soon at the Worldwide FAD Meeting in Buenos Aires next month!

http://thedailywtf.com/Articles/FrontAhead-Design.aspx