Monday, September 30, 2013

Leaks or Marketing?

As the latest round of leaks make their way through the copy-me-too sphere... are they really leaks or are they a marketing ploy on behalf of the marketing teams and/or publisher?

The manufacturer's love this stuff because they get all sorts of buzz, mindshare, and with any luck they get to sample the public to determine just how successful the launch might be.

The publisher's love this stuff because is increases their readership. Right or wrong the public enjoys a little drama and a new secret project is the way to do that.

When I think about a a leak, however, I'm always thinking that it's a "deep throat".... when it's not really a person at all. In some cases it's just some detective work akin to dumpster diving. Some folks are reverse engineering the manufacturing breadcrumbs... but for all that effort...

The one thing that always seems to be missing is the names of the people making the discovery or the leaker. So I'm not certain that there is one.

**good luck** to Nexus 5

Sunday, September 29, 2013

I was once a RockStar programmer

I think I *was once* a rockstar programmer. I was (a) more productive than my peers (b) understood and solved complex problems (c) intimate knowledge of every part of the stack from the CPU, CPU cache, memory and disk systems, all manner of device drivers, complete knowledge of the OSI stack, and the internals of DOS, OS/2, Windows and AIX; as well as realtime systems. Later when I started developing transaction systems for business I had managers who treated me like a rockstar and they allowed me to behave like one. (releasing my inner a-hole).

I'm reformed now. Many of my peers type faster than me and there are many more of them. Most complex problems are no longer complex thanks to a lot of open source and the internet. Since I no longer work on projects that have that sort of demand I have allowed a lot of that information to flush my cache. It's nice to refresh from time to time but not required to do my job.

And finally, my managers are more sensible now. The industry as a whole has changed. Would-be rockstars are being "handled" (McConnell says fire them; "debugging the development process") and processes like agile try to alter the set-point.

I still enjoy the work, the challenge, the stress, and the "problems". But I no longer want to be a rockstar. Just show me the money instead.

UPDATE: Actually I was a rockstar programmer in more than one way.  At the time I was a Rockstar programmer I was also a Rockstar. I was in a band, we had a recording studio and we recorded 2 albums.

Friday, September 27, 2013

Apple Radio

I like my Pandora service. I've tried the others but either they were too expensive or constantly trying to sell me something. Today I'm trying Apple Radio. The UI experience on my iPhone and desktop are ok. I had to make a point of disabling my iTunes from downloading media on the cellular data network. However, not everything is rainbows and unicorns.

I want to know if Apple under estimates the ability of the average iTunes user to locate the BUY button or are they hoping for accidental BUY clicks. The BUY button appear in the play window, the mini-player window, and in the station history. Some of the buttons are camouflaged (probably unintentionally) and others are practically on top of other controls.

Given that the app-store return policy is non-existent I'm not sure what trouble this will bring.

Gaming the system

With 20% of the yelp reviews being forgeries what is the point of trying to develop an online brand for yourself? It would seem that most online users are aware of these numbers and are naturally skeptical of any sort of online information or propaganda.

Thursday, September 26, 2013

FSMDD (FDD) - Finite State Machine Driven Development

There isn't a NEW method, model or process for developing software that does not seem to have a 'DD' as a suffix. eg; MDD, TDD, DDD, BDD... I'm not certain if this suffix is supposed to provide instance credibility or if it's just a vogue thing.

So I hereby declare that FSMDD or FDD, for short, has arrived.

FDD is the implementation of a finite state machine that whose nodes contain state specific information that is used to operate/compute against an event context. Individual FSMs can operate like subroutines with fanOut/fanIn, call, or fork -like process control to/from other FSMs.

What makes this particularly strong is that (a) by reducing the number of conditionals in the compute portion of a state node testing is simplified (b) by using the state machine representation, as data, it is trivial to graph in order to provide self documentation (c) once the inventory of compute-operations is complete the assembly of the individual FSMs is fairly routine.

As a side note: (1) inventory is constructed. (2) FSMs are assembled.

Another interesting side effect is that capturing the before and after states constitutes "change".  That change can be captured in the FSM machinery instead of the user-space. Making the code more audit-able.

This is just the beginning.

UPDATE: comparing two implementations of the same system; one using this approach and a second using a traditional approach. The comparison of the input/output should be the same and the code they share should be considered constant in time. The FDD approach will have a slightly higher cost since there is a framework directing the code, however, the benefits (readable code, readable logic, visual directed graph, more reusable code, multiple code generators and snippet languages, easier to test) may outweigh and cost.

The FDD implementation is easier to test because the executable fragments do not have conditionals in them and therefore they are easier to test. Consider that a 10K LOC function might need 10K test cases. One need to hope that they get 100% code coverage.  Now consider the FDD approach where there is 10K functions with 10K test cases. The likelihood that the FDD approach is going to provide better coverage should be intuitive.

Before you say that on needs to consider the interaction tests in the FDD approach; consider that it's going to take a lot more than 10K tests to validate a 10K LOC single function.

Presenter or the Topic - which is to blame?

If a presenter is moving frantically from the left edge to the right edge in order to explain some topic. Is that a reflection of the complexity of the topic or the preparation and understanding of the topic by the presenter?

Saturday, September 21, 2013

Do you really want to improve your code quality? Try this!

I have been tooling around with a code generator. Some piece of code generates some other, intermediate, piece of code; which is then compiled. However, along with the intermediate code I also generate state diagrams using graphviz. The outcome produced some wild results. (a) I caught more of my own bugs before letting them escape into test. (b) as part of the documentation it allowed the product owner, QA, audit etc... to validate the requirements with the code. This is MUCH better than writing your own flowcharts or even TDD, BDD, MDD, DDD, etc...

The second observation. While the code was being generated from artifacts in a database; with the intent that different code fragments that were stored in the DB would be reused as-is; It became necessary that the generated code (a)implement immutable variable names, (b)class attribute names, (c)function names and (d)class member function names. Which if you have not guessed it flies in the face of everything we know but let me explain.

1) Given a class User with a string attribute Name; we know a few things:

  • a class is nothing more than a container of attributes and methods
  • User is such a container with an implied semantic that it describes a user
  • and that there is a Name attribute in the User container
  • of course User.Name could have many semantic meanings
2) Given a class Printer with a string attribute Name; we know many of the same things.

Since the code I was working on was completely green field I was generating many new classes, structures and interfaces. I found myself copying code and attributes from gist to gist. As the code got more complex I found myself using lots of reflection (I'm not sure which came first; the complexity or the reflection) And one strange outcome was that I started ignoring the semantics of the class and just started copying like named attributes.

You might find yourself saying that this is all on me.  You'd be right too. But assuming that your language of choice implements a proper inheritance model or even proper OO structure -- all of that is a complicated waste of time. What happens when you are looking at... WindowsUser.Name and UnixUser.Name? Or Windows.User.Name and Unix.User.Name? Nowhere is this more obvious than Duck Typing. But even here you have the type and none of the semantics.

If you truly accept that the "class" does not really offer but the loosest semantics and that the strict semantics are on the actual attributes then you'll see the benefits of getting the names right across classes, structures and such.

Friday, September 20, 2013

Who is writing your testcases?

Cucumber is just a way to wrap RSpec tests with a non-technical syntax. Any supposed benefits of it go to waste because code is only interesting to those who are working in it. Quit writing cukes unless you can honestly say that there is someone reading them who would not understand pure Ruby. --Kevin Liddle
Instead of trying to find ways to flatten the organization, share blame through consensus, programmer commoditization, maximize profits at the very edge of the bell curve where it's just not practical...

If there is one thing that the Agile Manifesto does but does not say... smart people do smart things, most of the time, and get stuff done.

Wednesday, September 18, 2013

The Ubuntu edge

Even if canonical manages to deliver on the promise of the Ubuntu edge I think they are going to face an uphill battle all the way. Now that I have downloaded the latest iPhone, version seven, I realize the importance of incremental software user interface changes. 

The killer interface would've been accomplished had Apple been able to implement both the legacy and the next-generation interface simultaneously. The classic interface would've been helpful as some of the slower to adopt users would not panic or be forced to use more traditional pushbutton phones. 

The next few weeks will be very interesting for Apple's future.

GoLang - leave leave the cruft at the door

It's hard to take an programmer and would-be technical author seriously who lists MS Office tools on his resume. (now I need to go back and check my resume) But what is really annoying is that one author wants the go team to add Generics and the other is looking for some Object-Oriented features. I'm not an expert on the GoLang mission goals, however, from my vantage neither G or OO are particularly interesting... and if I needed them I'd go back to writing in Java.

I'd prefer that the GoLang team focus on some more pragmatic ideas. I find myself using interface{} and reflection more than I want. I'm not certain if that's because I'm trying to circumvent some language feature or if this is the natural way to solve my class of problems; in either case I'd prefer that the GoLang team make the corrections but it's not important as I like it.

Another statement comes to mind. Something like: GoLang was not designed to be terse but correct. (or something like that.) I just don't see G or OO making GoLang more correct.

Monday, September 16, 2013

Focus on the problem not the tools

Reviewing some code that it only about 5 years old I was sad to see I broke some common sense best practices. The code was a mix of http server, serial port i/o, database client, and device driver. Even though this was the 2nd generation of refactored code I still see a solid coupling of i/o and workflow or behavior.

The reason the code is so hodge podge is because the standard C program does not abstract enough of the environment away in tools or libs unless you're willing to depend on mountains of dependencies. And 4 years ago it was not a simple task to link serial i/o with an http server in a compiled project (scripting was not an option)

If I had to do it all over again... GoLang.

Sunday, September 15, 2013

Apple's customer service continues to slip

I just left a retail store after making an appointment week in advance. My expectation was That an Apple technician would replace the damaged or defective battery on my laptop. Whether it cost me anything to replace was not point. In fact I was there to pay the  $129 replacement fee.

The issue is that Apple wanted to take my computer into custody in order to effect repairs. That was simply not an option this time. As Jordan explained to me this is pretty straightforward replacement however he didn't have any technicians in the back and although he was a technician himself he was not authorized to perform any technical repairs that day.

So what is the point of making an appointment with an Apple genius if they can't make the repairs when you're at the store. It's the sort of experience that makes owning multiple computers at a much cheaper price the better alternative. I can now envision owning multiple Google Chrome books. The work that I'm pursuing currently could be satisfied with any sort of Dell machine running a virtualized Linux machine.


Friday, September 13, 2013

Who is going to wing the openstack API war?

Does it matter? Actually. Yes! When Microsoft and Sun wrestled over the java APIs there was a real chance that java could have been erased. 

Thursday, September 12, 2013

GoLang when to use a struct and when to use a pointer?

The GoLang language experts like using pointers and I have to agree that it's better to pass around pointers than it is full data structures. Of course this upsets the garbage collector and it's not very functional when you start talking about immutable data... On the other hand there are a number of one-liners that make programming fun.

Here is a pointer version:
query := new(Query)query.I = 1query.Select()

Here is a struct version:
Query{I:1}.Select()
In this case the Query structure is meant to hold a collection of named parameters for a well known DB query and it is very short lived. In the struct version the select() can be called as a one liner making the code very simple and short.

Message queues are fun but they won't save the world

There are many more anti-patterns for using message queues then there are idioms. Message queues are useful for marshaling events around the system of services. However things go very wrong when the object being ferried around her system are larger than some marginal set. The limit for a message to item should probably being no larger than a single TCP packet somewhere around 1K. this is just one case there are many more.

Monday, September 2, 2013

Purpose built IDE's.

I really like the brackets editor. However it seems to be a special-purpose IDE. It supports JavaScript and other server-side client-side editing tasks and files. If your ecosystem is exclusively Implemented in JavaScript both client-side and server-side than brackets would appear to be an ideal IDE. 

However in the real world this is not practical. Most projects are poly-lingual meaning that they include languages and features from multiple sources. For example building web application using go requires both syntax analysis and Lint plus HTML JavaScript CSS. Additionally you need to be able to edit various dot files access files configuration files all of which would be nice if there were some pics highlighting for.

On the other hand generic editors like that brains and clips and NetBeans seem to miss the mark when it comes to building apps. They have certain customizations that allow them to build apps for a select set of projects Or project types. These IDEs will always be a work in progress.

At the end of the day you're probably better off picking your favorite text editor like ViI, Vim, eMacs, sublime, textmate.

Sunday, September 1, 2013

I finally found a practical use for domain specific languages.

I finally found a use case that makes sense for DSL. In truth it's not really a DSL but a T-DSL. The T stands for transformative. A perfect example of a Transformative-DSL would be something like spec. Where TSON and XML are simple containers for the DSL.

As an example of a DSL anti-pattern; consider the puppet DSL. The DSL itself is constructed in Ruby and the configuration that drives the actions are also constructed in Ruby. This method of configuration tightly binds the configuration itself to the underlying DSL implementation. The configuration is no longer transformative across like patterns. It depends on Ruby itself being cross-platform. Thus making Ruby dependency the overall architecture.

another bad day for open source

One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...