Site Sponsors:
Software Release: The Hershey Font Explorer 
Almost a year after the initial release we have been able to share a version of the Java Desktop Application created to explore, repair, and convert the Hershey Fonts.

Designed to show-off Dr. Hershey's accomplishment, by way of a bonus one can also review the marvellous efficiencies of the "R Format:"

Feel free to download the Java here.

You may read more about the project here.

The HTML5 + CSS3 + SVG Rendition also looks marvellous (even if I do say so myself :)

Enjoy the journey!


[ view entry ] ( 2107 views )   |  permalink  |  related link
PC Signaling & IPC Efficiencies 
Linkedin: Observations on Qt Signalling:

Qt Design Lamentations

I still do not understand what was wrong with simply using structs... Indeed, even when it comes to IPC, savvy consultants have always liked marshalling such things into XDR/RPC packages.... Allot like "Bundles" or "Parsables" on Android, once a standards-based out-of-process marshalling has been ensured, data can pretty much go everywhere. The only benefit to not having so many struct-version compile-time changes is to ensure that any time-frozen stringy-application will break someday?

Data Interopt

When it comes to IPC, savvy consultants have also always liked XDR/RPC. The cornerstone of CORBA, many are gratified that - years after Microsoft upset the apple-cart with their COM/DCOM nightmare - that places like Google's GWT are finally abandoning the fat-and-chatty XML (and even JSON!) world for things like good 'old XDR.


Why did we ever get into this nightmare world of passing strings? Because - at the time - Microsoft did not like things like XDR because the transmission favoured Motorola (natural order / big-endian) format over that strange INTEL (little-endian) format.
(click to enlarge)

Many of my friends at MS felt like they were being picked on. Today however, with AMD / INTEL computing speeds being what they are in multicore, who the heck cares?


Looking at messages more as octets than double-byte characters results in transmissions that are ever-so marvellously faster, as well as often laughingly more efficient & secure than these "string things." While understanding protocols from the wire-up is tougher on the commodity-developer, taking the time to learn about things like binary efficiencies is invariably massively easier on the computer. --Many feel that weighing system performance (as well as genuine security!) over developer-ease and industry convention (homogeneity is - by very definition - insecure) is one of many long forgotten absolute necessities of designing larger-scale enterprise systems.

Lean, Mean ... and Green?

Of course, better performance means allot less switches, routers, network traffic, and computers... Such effective weight loss surely spells less rack-space, lower utility costs ... and is therefore allot easier on this spaceship that we call earth, too?

While knowledge is indeed power, perhaps wisdom might yet save our planet? :-)

Indeed, when it comes to why-the-heck use anything other than structs or XDR under QT, I remember wondering why folks ever used such silly & unsafe string-mechanism as that Qt signal tomfoolery. --For decades, marshaling structs between things like CORBA skeletons / signatures have been doing much the same thing, yet providing full-speed end-to-end type safety via delivery systems such as RPC. When it comes to stark type-safety & efficiency, why not use it between process, as well as between computers? While a bit overkill for local signal-signatures, rather than being so string-generic even a humble struct surely might be used?

CORBA Problems

Of course, with the CORBA type safety comes a problem of routing / scaling / and using generic turnstiles such as what we see in Spring Integration. Resolving those problems are what the Internet Inter-ORB Protocol (IIOP) and CORBA Services are all about.

Olde-School Bestfficiencies

Yet, come to discussing Java in a C/C++ forum (bad idea?), it is fun to note that both generic (common message header -w- size fields (etc)) - as well as all competent security (bit-level field encoding, etc.) remains ever in the realm of the absolute efficiency folded into those 1970-someting transactions... -For more secured transactions, even today it seems that only a blast to that transactional-past can be allot more readily 'rollingly obfuscated... as well as a whole lot more efficient?

[ view entry ] ( 2487 views )   |  permalink  |  related link
Waterfall & Agile - Can't We All Just Get Along? 

Big Need

Working with the Pentagon, one discovers that planning works like any other big business. There is a very real need to let people who are giving you lots of dollars know what they are going to get for their money.

Indeed, from DoDAF to UML, the designs we generate - as well as the software re-use we plan - often needs to be pretty specific. -Not only are lives at risk, but in a time when national defense is rapidly loosing funding to "social progress," the Waterfall approach is increasingly important. Why? Because every dollar counts. More than one organization can be involved. Meticulous planning is required.

Old Patterns

In general, many have discovered that - the bigger the undertaking, the larger the need for comprehensive planning - sometimes down to a demonstrative code-level / integration test plan.

Conversely, when it comes to our prototypical, polar, or recursive development activities (modernly known as "Agile") the need to take a sprint down the requirements de-jure, manage our burn-down-lists, test, and even continuously integrate, are time-proven ways to keep both system & software teams accountable.

Unfortunately, many folks do not know how old "Agile" techniques truly are! Rather than understanding that Waterfall and Agile have always worked together, I often discover people saying odd things such as "we are an agile", or "we are a waterfall" company?

Indeed, when someone is handing you a check for hundreds of thousands - or millions - of dollars, rather than expecting the "trust me, we are agile" mantra, or “waterfall will get us there,” it is not beyond the realm of realistic exception to have someone say "that is not enough."

Strategy & Tactics

Of course, software development is all about patterns. When it comes to the unnecessary camps between Waterfall & Agile, I therefore like to tell developers that – for any large undertaking – there are usually two (2) different plans: The Strategic, and the Tactical.

Sound like warfare? Perhaps. But strategic and tactical planning patterns are found in several other places, as well.

For example, in large-scale, modern business, the need for the “where are we going” over the “what are you doing” techniques often find their expression in an “Enterprise Architecture”, and the ever-present “Implementation Architecture?” While the delineation between the two needs might indeed seem a little loose at the moment, such is the way of a work-in-progress abstraction.

Nevertheless, in highly visible, large undertakings I propose that Waterfall is the strategic, while Agile – the tactical? Why? Because not only can BOTH Agile & Waterfall be rightly required, but for decades they BOTH have worked together just fine.

New Idea?

In warfare, knowing where we are going, as well as how we are getting there, are important. Considering each is why both strategic & tactical planning are important. Waterfall planing, Agile execution.

In software, and from time to time, surely both Waterfall & Agile should be found co-existing. Certainly whenever huge amounts of resources are to be expended. Individually, both undertakings just make sense. Together, both Agile & Waterfall can help us work miracles. Just like in battle.

Heads & Tails

Whenever both Agile & Waterfall approaches are working well together, we can certainly see the strategic, as well as the tactical aspects-in-motion. Yet, because the concept of creating a synergistic cooperation between Agile & Waterfall is unique to many, perhaps a new term is required?

So I was thinking (a dangerous pastime, I know!) -In as much as the collaboration between the strategic & tactical dates back thru a millennia of combat, rather than soft-warfare, perhaps a new moniker is required. Whenever tactics and strategies begin to complement one another a tad more classically than they presently might, then perhaps we should call it waging 'warefare, instead?

Enjoy the Journey!


[ view entry ] ( 2743 views )   |  permalink

<<First <Back | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | Next> Last>>