Paul C. Williams

Interfacing Technology & Business
View Paul Williams's profile on LinkedIn

Monday, December 23, 2013

Bitcoin is going mainstream

This morning I read on Forbes that is going to start accepting bitcoin payments, probably through Coinbase or Bitpay.  These two companies are really poised to rake in all the spare nickles floating around the market.

In related news, Belgian mobile telecom Mobile Vikings is also accepting bitcoin payments.

This is really good for the stability of bitcoin, which will see the wild deltas in valuation start to settle down as soon as there's a few arbitrage experts around to take advantage of any deviations from real value.

This is following my predicted model for bitcoin stabilization, and someone is making a ton of money.

Friday, December 20, 2013

Of whales and sardines: sales in professional services

Spend long enough in a professional services project environment, and you'll notice a tendency over time to chase "whales".  Large projects with expansive scope that look great because of their big price tag. These projects also tend to be very complex, with many moving parts. Whale projects require a higher staffing level, so more management oversight. The customers are more demanding and have more quality issues.

I'd like to take a moment to contrast that to a sardine project.  Sardines by contrast are simple creatures. They have similar needs to one another, and are often found in groups.  Professional services organizations often start out with sardines, but are tempted to move toward whale projects as cost structures start to balloon before efficiency measures and economies of scale kick in.

While a whale might provide meat for a village and any one sardine isn't very interesting or filling, but if one is efficient enough at pulling a volume of sardines at a time, it might just be as valuable as that whale you spend so much effort hunting, trapping, catching and butchering.

Image credit: Karen Kasmauski & Getty Images/Science Faction

Wednesday, December 18, 2013

Why do websites still have local log-in systems?

I was shocked today when perusing the PC Pro website, that they still require you to create an account on their system to post a comment. To be fair, I'm not contesting the usefulness of having an authentication mechanism. It keeps us a little safer from anonymous diatribe and vitriol.

But why would PC Pro or any other website want to maintain a safe authentication scheme, manage user accounts and all that when the apparatus of Google, Yahoo, Facebook, Twitter and others can be used so effectively? They're easy, cheap, effective and secure enough for most general use applications on the net.

Tuesday, December 17, 2013

Arbitrage opportunity for bitcoin payments

I see a huge opportunity coming up. Retailers everywhere are (always) looking for a cheap way to attract more purchases without huge valuation fluctuations. Bitcoin owners want to determine a practical and legal use for their currency. Bitcoin values are trending up rapidly. With demand and fluctuation comes arbitrage opportunity.

Sunday, December 15, 2013

Consumer grade hubs suck

I had to share a ethernet drop between a couple of computers in my home office today. To achieve that, I connected  a little Netgear 5-port 10/100/1000 hub to my drop and sent a couple of ethernet lines out to the nodes.

This morning, I was having connectivity issues out to the internet. Connections were spotty, the speed wasn't fabulous and latency was much higher than normal. A trip to confirmed that I wasn't seeing what I usually see.

I took the hub out of line, so that it was no longer between my very awesome Asus RT-N66U router and ran the speed test again. Pouf! Problems gone; speeds back up to 50+ MBPS with fewer connectivity and latency issues.

Note to self: consumer grade hubs generally suck.

Saturday, December 14, 2013

Teenage is an intimidating time

My daughter Hannah pictured here is currently in 8th grade. As we tour high schools looking at the different programs that are offered, I can't help but feel intimidated. Of course, she's too cool to be intimidated by such things -- she just wants to make sure her friends are in the same school.

There's a lot of focus on the programs that prepare kids for college, and all the work and activities that kids will be expected to participate in to qualify for these programs. Nearly all programs are engineering-oriented.

At a time in which we lament grade inflation at schools like Harvard, there is ongoing scandal at secondary schools regarding the standardized testing, and a constant fear that American colleges aren't preparing students for the work world, I have to say I am amazed at how much energy is put in to designing compelling-looking programs. One would think that with all this energy invested in these programs that there would be less of a problem with our education system.

One program commonly implemented in our area is the International Baccalaureate (IB). This program claims to be the most rigorous liberal arts program in the country, focusing on well rounded students ready to enter into the most prestigious schools in the country.

And, I have to say, based on the presentations and interviews with the IB students, it seems an impressive program. But with a stated 5 hours of homework nightly, as well as a requirement for sport and community service and the highest academic standards at any given school, this program sure feels scary to me, and I'm not even in it.

Friday, December 13, 2013

Android modal in-process dialog

It turned out that adding an in-process dialog to the previous example of an asynchronous task was pretty simple.

With a minor change to the AsyncTask I showed in the last posting, I was able to get a handle to the dialog in order to dismiss it at the appropriate time.  Dismissing it in the finally block ensures that the dismissal happens even if there is an error in processing.

Android network development: network activity on main thread?

If you, like me, are learning Android development, and your Android application requires network access, you might see an error like this when you try to access the network:

E/AndroidRuntime(673): java.lang.RuntimeException: Unable to start activity
ComponentInfo{com.example/com.example.ExampleActivity}: android.os.NetworkOnMainThreadException

It turns out that Android has disallowed network activity on the main thread since version 3.0 (Ice Cream Sandwich) or so. This is done to prevent UI blocking during network activity. The fix is to handle the network activity in the background. This sounds scary, but fortunately the developers added a helper abstract class AsyncTask to ease the process.

And it is easy. Here's an example AsyncTask that uses an existing network utility to look up product details based on a string SKU:

private class GetProductTask extends AsyncTask<String,Integer,Product> {
    private String sku; 
    protected void onPostExecute(Product p) {
        try {
            if( p == null) {
                // alert the user that we couldn't find a product for the SKU
        } finally {
            // clear the throbber

    protected Product doInBackground(String... params) {
        this.sku = params[0];
        // ProductCatalog.locateBySku() is a network activity
        return ProductCatalog.locateBySku(sku);

The generic parameters <String,Integer,Product> are the input type, status type, and output type respectively. That is, in our case, the doInBackground() method accepts Strings and when successful onPostExecute() is passed a Product.

This is called simply as an execute to a new object:

new GetProductTask().execute(sku);

You can choose to set up a throbber to communicate to the user that there is an activity in progress.  I made mine modal so that no other data entry could occur while we wait for the network.  That's a different blog posting.

There is also another method you can override, the onProgressUpdate() routine which would be passed an Integer, but in this case I didn't need it.

Thursday, December 12, 2013

Installing Ubuntu using network boot (PXE / TFTP)

I feel like such a stud!  Using a windows TFTP server, I loaded and installed Ubuntu 12.04 LTS Server on a 1U HP Proliant server using absolutely no media.  This was not super easy, because the TFTP server doesn't like relative paths, so I had to be tenacious to overcome the limitations.

My reward: a fully operational battle station Ubuntu Linux Server.

Saturday, December 7, 2013

Innovation is getting watered down

The Wall Street Journal has an article about the audacity of some businesses to tout their most recent product evolution as "innovations" by using the case of "Peanut Butter Pop Tart" being labelled as one.  This tendency of leaders to label such adjustments as innovation waters down the term and belittles the truth of innovation.

What is real innovation?

Thursday, December 5, 2013

Wednesday, December 4, 2013

Stay Foolish. Hungry is helpful too.

Perhaps no man has affected the way we conceive of leadership, entrepreneurship and innovation more than Steve Jobs. His oft-quoted phrase given during the commencement address in 2005 to Stanford University grads "Stay Hungry; Stay Foolish" is usually interpreted to be an admonishment to be relentless in the search for users, buyers and funding. I think this misses the mark in a very profound way, and minimizes the true genius of the statement.

Tuesday, December 3, 2013

Why are KPIs troublesome in professional environments?

There's no argument: Key Performance Indicators (KPIs) are useful. We, as busy people, must distill complex processes into easily understood and manageable chunks.  It's hoped that most KPIs, if improved, would actually impact the performance of our organizations. Why do we latch on to that so readily, and why doesn't it always work?

The Theory

It's a business school mantra that one cannot improve that which is not measured.  Scientific management needs to have easily gathered, analyzed and understood metrics in order to know where bottlenecks exist, and what parts of the process are ripe for optimization.  This is relatively easily done in some industries.  In manufacturing, you can measure process flow through each manufacturing line.  Similarly, calculating the number of units in various work-in-progress states is straight-forward.  It's very easy to see how decreasing process time improves process flow thus productivity and profitability.  Reduction of works-in-progress (which in manufacturing is equivalent to unproductive capital) directly affects the cash flow of the operation as well.

Both of these metrics can be used to compare the average values to specific measurements on specific lines to determine if a specific manufacturing line using a standardized process.  A manager can easily see that manufacturing line A has difficulties during the 2nd shift, because it's throughput is 20% lower than average. Similarly, we can look at line D to see what they're doing so much more effectively because their throughput is 20% higher than average.
Hypothesis Testing: Determine statistical significance
of a measurement against the known operational range.

Pay For Performance

It's natural then to implement a pay-for-performance scheme based on KPI measurements. In fact, KPI measurements can be used for a host of management processes that are functionally equivalent to pay for performance.  Consider an annual performance review that may use a KPI measurement as an objective component for the review. If the annual review might in the eyes of the reviewee be used as justification for promotion, termination, or even to which work space the employee gets assigned, it's important enough to the reviewee to ensure maximal results. The situation gets even more important for middle managers who may have variable compensation that depends on KPI targets.

KPI Development & Ownership

How are KPI targets developed?  The textbook answer to this question is to collaboratively decide using a cross-functional team of stakeholders from all levels to decide what metrics to use that accurately reflect improved support of the organizational strategy.  With a shared sense of ownership grounded in a firm understanding of the organization and strategy, all stakeholders have an incentive to make their metrics better.

The prerequisite here is that all the stakeholders really understand what the strategy is, and how their role supports the strategy.  Believe it or not, this understanding is exceedingly rare.

What seems to wind up happening is from somewhere on high, a directive is handed down that such-and-so will be measured, and we shall strive to improve this measurement.  In software development, the new measurement might be, in the most naive cases, lines of code, or bugs resolved.  In more enlightened organizations the metric might be estimated hours vs. actual hours for project execution.

In either case, those who are most subjected to the result of the analysis of the metric may not have much control over the outcome.  In the estimate vs. actual case, we might make the argument that the team ought to be good enough to estimate the effort required to execute the task. It's not uncommon though for teams to not know enough about external factors, such as specific integration requirements, or nonfunctional requirements like performance to accurately foresee all impacting tasks.

The net result is that contributors have a feeling of helplessness in affecting the KPIs they've been committed to.

A Perverse Incentive

What happens when contributors are impacted career-wise or financially by KPIs that were assigned to them by a management stack? They game the system. Teachers, held to KPIs encoded in law, cheat to improve their class test scores. I imagine the teachers and officials in these cases, already woefully underpaid, feel somewhat justified in their decision to cheat. Their KPI measurements are frequently impacted by factors outside their control. It's hard to get a kid to care about what I think most rational people can agree is a bogus standardized test. Kids can have impressively accurate BS detectors.

Kent Arnold, A former manager of mine once said about KPIs that "All software engineers are game theorists". By this he means software engineers and other professionals are savvy enough to figure out what is being measured and improve exactly that. Unless the metric actually supports an organizational goal directly, the KPI might encourage a behavior that doesn't support productive activity. Is 100% test completion a good target? What if a software developer were to, in the name of boosting the metric, decide to exclude tests that might not succeed? Perhaps the test suite is sandbagged with trivial tests to reach a 90% success measurement. In either of these cases, is the organization's goal of lowering maintenance costs and higher customer satisfaction achieved?

Are KPIs doomed?

This is a somewhat depressing line of thinking. Are metrics are so deeply flawed that they cannot be used in professional organizations?

I don't think so.  More importantly I think that the "right" way to implement KPIs will actually benefit morale and employee engagement while simultaneously providing better insight into the operations of the organization.

In an upcoming posting, I'll outline a model for generating useful KPIs in professional organizations.

Friday, November 29, 2013

The Long Tail of Making Things Work

There's been quite a bit of news circulating these days about worms or other malware that is starting to exploit what we have started calling the Internet of Things.

The Internet of Things is a confusing enough concept.  Everything from your fridge to your thermostat to your TV and all the points in between like routers and VoIP bridges are connected to the internet, and most of them run Linux.  These devices -- which without doubt make our lives better -- make our home networks as juicy targets as big corporate networks, but a lot softer.  Be honest with us: have you gone to the lengths to harden your home network?

The Long Tail of Making Things Work

What happens after a company has made a product?

Of course, they sell it.  

In a corporate environment, as customers we demand a certain level of maintenance.  This maintenance ensures that the firmware for our WiFi routers and other appliances is updated with the latest patches and bug fixes. People have their jobs on the line to make sure that security threats are mitigated.  We pay, on average, 18% of the purchase price annually to make sure software and firmware is up to date.  When the hardware is no longer viable and cannot be reliably updated, it is replaced, often at great expense.

This maintenance, to keep things working and safe over time is the Long Tail. It's an immense amount of work that never, ever stops. 

This differs from the home market in a radical way. In the home market, we are used to microwaves, clothes driers and TVs which we purchase once and never pay for again. We would refuse to pay $180 every year to update the TV's software; and so it stays the same.  Issues that were discovered, exploited and solved will be ignored for these devices, for the manufacturers will spend their energy on development of the next new product that will garner revenue, not the last generation which consumers will not pay to update.

DDOS Fodder

These devices, with security holes in time mapped like the catacombs under Paris or Rome, are the platforms which are used to launch a DDOS attack against whatever hapless business runs afoul of some extortionist scheme. Yes, your old Linksys router might be one of ten million devices, sending 3 requests per second against a specific Yahoo server to disrupt some service.  You will never know, of course, because the traffic is so light for any one device that the additional bandwidth gets lost in the noise of YouTube and Google Docs.

Avoid the Trap

Some consumer electronics companies avoid the trap. Among consumer electronics manufacturers, Apple has the best record of keeping software up to date, by using the same software base for 3-4 generations of devices, and making it harder to avoid updating than it is to just update your software.

Others, like printers or WiFi router manufacturers do not succeed as well. These devices languish on the desktops and in the closets of homes and small businesses everywhere, ripe for exploitation.


Be picky.  Choose your devices not for their current updates or implementation of the newest 802.11 abcgn-mouse protocol; rather make sure that you've looked at some 3rd party controller firmware for whatever device you have. 3rd party firmware does not need to justify to shareholders why it is spending 18% of revenue on maintenance of legacy platforms .. it can be worked on and kept up to date just because its fun to do so.

And, of course, disable any outside access to your networks.  You don't need it.  Really.

3rd Party Firmware

Wednesday, November 27, 2013

Which technology is better: X or Y?

I always wonder why these kinds of arguments exist. Technology exists to solve problems, and at any given time a particular technology tool may solve a problem.

In reality, the question which will get answered isn't "What is better: X or Y?" but "What do you find more fun: X or Y?"

So, the question to ask is not "What is better: X or Y?" Instead, we should ask: will X solve my problem faster than Y, or will Y be better than X today.

The factors involved in this analysis vary from project to project, but should include the following:
  1. Is there prior art that can be leveraged in either X or Y, so that I have less work to do to get to market?
  2. Do I or my existing team have an existing competency in X or Y that I can leverage?
  3. Given my existing knowledge, in which technology X or Y will I more rapidly be able to make changes?
  4. When I need to hire assistants, will I more readily find help with X or Y, and will that help be at the level I need?
The answers will be unique to you, and defined by your existing experience, and the experience of those around you.

Big companies are not the only entities with "legacy" infrastructure -- we all have a tyranny of legacy to contend with. It's important to partner with your personal legacy and co-opt your legacy for your purpose, rather than force something radical to change because someone thought that X was better than Y; for someday, Z will be better yet.

Image courtesy of Bill Longshaw at

Monday, November 25, 2013

Innovation Expanded

Over the last week or so, I've been reading "The Idea Factory", which is an interesting collection of stories about the evolution of Bell Labs.  I find these stories interesting, because it gives us insight about how the creative process works in a technological skunk works.

Right now the stories are focused on the development of solid-state transistors. In the late 40s and early 50s these devices could be reliably manufactured, but nobody really knew what to do with them.

I think we should all be able to agree that the invention of the solid-state transistor is an innovation of the most important kind.  But, to my astonishment, no!  According to the book, the technologists at Bell Labs did not believe that was so ... yet:
...Innovation was not a simple action but “a total process” of interrelated parts. “It is not just the discovery of new phenomena, nor the development of a new product or manufacturing technique, nor the creation of a new market,” he later wrote. “Rather, the process is all these things acting together in an integrated way toward a common industrial goal.”
...A Bell Labs development scientist named Eugene Gordon, points out that there were two corollaries to Morton’s view of innovation: The first is that if you haven’t manufactured the new thing in substantial quantities, you have not innovated; the second is that if you haven’t found a market to sell the product, you have not innovated.
This has really impacted how I think about innovation.  I used to think it was all about creation, but in this light it is also about production and dissemination.  These are different parts of the product life cycle, but truthfully must be incorporated into an innovation process before adoption can occur.

Image courtesy of Janaka Dharmasena at

A strategy lesson from my wife

My wife is a constant stream of wisdom. She mentioned this to me the other night, before we were off to a weekend visit to Wyoming, and had a few house chores left. It is an instant introduction to strategy and tactics in prioritizing tasks.

Tactics: If you want the kids to fold their own laundry, make sure that's done first.  Make sure tomorrow's clothes are in today's laundry.

Strategy: Do the whites before bed.  If you're too tired to finish, you can leave them in the drier.

The take away here: Unblock others. Identify what tasks are required soonest. Figure out what can wait and do that last.  Finally, make sure your tactics and strategy don't work against each other. Don't do the whites last if you really need that white shirt for tomorrow.

What business lessons have you picked up from unexpected sources?

Image courtesy of zole4 at

Friday, November 22, 2013

Perfect Forward Security : Making bad guys work harder for your data

Every Solution Architect needs to be familiar with the state of data security technology. There is so much innovation in this space, it's hard to keep up.  The advent of elliptic curve encryption has reduce the computing cost of generating high quality keys.  Now the application of "perfect forward security" takes that to the next level, by introducing a protocol for generating session keys to prevent a single compromised key from allowing large quantities of data to be decrypted.

It's math heavy, but if you design secure systems, or are responsible for sensitive data you must know this.

SSL/TLS & Perfect Forward Secrecy

Twitter just announced that they're implementing this, and describe their lessons learned.

Both are worth the read.

Decade ago; decade from now... what is the trajectory of IT?

Sometimes, it's not easy to remember what life was like 10 years ago. This article compares how IT infrastructure projects ran a decade ago, and what would be different today.

Looking back: How I'd build an IT infrastructure today versus how I did it 10 years ago

The article spends a lot of time describing how cloud services have changed the way he would have deployed his IT services.  In corporate and enterprise IT, the use of cloud services isn't quite as prevalent yet.  I wonder if this is a foreshadowing of what the next 10 years holds for corporate and enterprise.

Certainly, my kids are getting used to cloud -- much of their homework is done on Google Apps for Education. My daughter collaborates in teams on papers and presentations using Google Drive. There must be a generational influence when these kids enter the workforce.

Still, I find it hard to overcome my own bias against cloud services. Especially with the ongoing revelations of NSA snooping on cloud services, data stewardship seems to continue to be a point of friction in migrating to the cloud for enterprises.

Thursday, November 21, 2013

My 4 Favorite Technical Interview Questions

Technical interviewing questions
When I'm interviewing candidates to add to my team of Java engineers, I want to make sure that I hire smart, thoughtful, self-starters.  I don't want to spend much time training them on the basics.  I need to make sure they can write maintainable code, and they have the chops to contribute to designs.

Once I've covered the basics of java coding, like knowing the construction of classes and objects, and other typical syntax, I get into some of the "heavier" lifting.  None of these is particularly difficult to answer, but the depth of answer gives great insight into the overall competency of the individual.

After I ask these technical questions, I usually move on to interpersonal questions.  In addition to being a great technician, I've got to assess how that person is going to fit in to the team. I want the team to challenge each other, but not to the extent of causing friction. There is always room for respectful debate as long as it can be directed to closure by an effective leader.

1. What is the difference between "final", "finally", and "finalize"?

This question, besides having the virtue of a cute alliteration, is what I consider the litmus test for "journeyman" Java experience.  The identifiers seem similar based on the name, but the use is totally different. The depth to which a candidate can discuss these features can be used to infer general Java language knowledge.  This is one of the few language specific questions I ask.

The "final" identifier is used to modify methods or classes to prevent polymorphism, or to modify members or variables to prevent changes to references.  "final" does not prevent changes to content, so if you require immutability of content, there's an additional step required.

"finally" is an often omitted 3rd part of a try..catch..finally block, which is guaranteed to run upon returning from the try.  This is used to release resources (e.g. close database connections).  It is sometimes used after a try block with no catch, to execute statements when control is returned either by an immediate return or an exceptional condition.

"finalize" is a special method in an object.  Similar to a constructor, the "finalize" method is called before the object is garbage collected, and can be used to free resources.  If the Java process terminates (normally or abnormally), the "finalize" method will not be called.  The designer must not rely on the "finalize" method, because there is no guarantee it will be called.

2. What is your favorite design pattern?  What problems does it solve for you?  Under what conditions would you avoid using it?

Design patterns are a great way for software engineers to communicate tested solutions to common problems. Even if the interviewee isn't familiar with the standard design patterns, chances are that if you allow them, they can communicate some kind of typical solution. 

Great answers to this question are surprisingly hard to come by. Most of the time, the interviewee can name a couple, common to the point of cliche, like MVC for which there are already frameworks that coders can hook in with.

A great answer to this question would describe how using a Facade or Adapter pattern allowed a seamless integration between a modern and legacy system with a minimal amount of fuss by adapting the legacy business methods to the new updated APIs, but fails to help when there are processing bugs that need to be resolved, and can complicate debugging processes.

3. What is your least favorite feature of your most favorite language? How do you work around this deficiency?

This tidbit asks the candidate to dig a little deeper and show us how much they've actually done in the language of the day. We can see quickly where the candidate finds a boundary and how the candidate responds to the issue. It also gives us insight into how deep the candidate has delved into the language as a programmer, what kinds of problems the candidate is likely to have been solving, and how skillfully they work around the issues.

My favorite part about this question is that I might get an answer regarding a language that is not on the job spec sheet. When I get answers that refer to a language other than Java, I know that I've got a candidate with real potential.  I can also dig a little deeper by asking about the language they identified.  I don't have to know the language in question, but I learn a lot from their level of confidence in presenting what they know. This can also help "loosen" the conversation, because it gets them talking about something they're passionate about.

4. Tell me about your favorite project.  What makes it your favorite?  What were you most proud of? What would you have done differently?

When I interview a candidate, I look for someone who is introspective and can draw on their experiences to determine what worked well and is worth replicating, and what could be improved. This question helps me to understand the candidate's design process and competency.  It also can give some insight into the complexity of their projects and how they've managed that complexity.

What are your favorite questions, and how do they help you evaluate technical candidates?

I invite you to leave your favorite questions and criteria in the comments below.  Let's have a discussion about identifying the best talent out there for our teams.

Image courtesy of franky242 at

Wednesday, November 20, 2013

Calling Java methods from RPG programs

Lately I've been working with a client to help them bridge a gap between their existing RPG programs and a Java utility library used to execute some network APIs.

There are a lot of resources around, but there is quite a bit of confusion about the specifics of the call semantics between the purely procedural RPG code, and the object-oriented behavior of Java code.

In Java, there's a magic identifier this, which references the current instance.  Because RPG lacks the concept of an Object-Method call, it cannot supply the reference to the object that becomes this.  Instead, when calling from RPG, a parameter is inserted before the first parameter.

As an example, given the following simple Java class:

public class Foo {
    private String bar;
    public Foo() { = null;
    public void setBar( String bar) { = bar;
    public String getBar() {

The RPG to set up and execute the java method from RPG looks like this:

 * Define a prototype for the 
D fooObj          PR              O   EXTPROC(*JAVA:
D                                      'Foo':
D                                      *CONSTRUCTOR)
 * define a constructor for strings
D makestring      PR              O    EXTPROC(*JAVA:
D                                       'java.lang.String':
D                                       *CONSTRUCTOR)
D    bytes                      30A    CONST VARYING
 * Define a prototype for the setBar method from the Foo object.
D setBar          PR              O    EXTPROC(*JAVA:
D                                       'Foo':
D                                       'setBar')
D                                      CLASS(*JAVA:'java.lang.String')
D                                      CONST
 * Define a string to hold the bar parameter...
D bar             S               O    CLASS(*JAVA:'java.lang.String')
 * Define a field to hold the foo object
D fooInst         S               O    CLASS(*JAVA:'Foo')
 * Define instances
C                   EVAL      bar = makestring('123456789012345678901234567890')
C                   EVAL      fooInst = fooObj()
 * Call the setBar method on the Foo object.  The prototype only defines
 * One parameter, but there is an implied first parameter that populates
 * the java "this" identifier.
C                   EVAL      setBar(fooInst:bar)

I'm not an RPG programmer, nor do I have access to an AS/400 to test my code.  Leave me a comment if this needs to be improved and I'll be sure to make the necessary edits.


Monday, November 18, 2013

I'm still waiting for Mr. Fusion...

According to NPR's science desk, there's some movement toward using cellulosic ethanol sourced from trash.  This is still a half-measure in my mind ... I'm going to hold out for Mr. Fusion.

Friday, November 15, 2013

Boss vs. Leader : Is it fair to polarize this distinction?

I saw the title image here floating around LinkedIn this morning.

There seems to be a lot of this kind of wisdom around.  I, for one, don't buy it.  It actually bugs the crap out of me.

I can agree with the Boss column.  We have all been subjected to bossy people in our lives, whether they are siblings or cousins, or just that bossy kid in our play group.  The behavior meets the criteria in the boss column.

I'm not sure I agree with the Leader column.  In the leader column we see behaviors that I ascribe more to a mentor or cheerleader.

The difference is what linguists call "code switching", or being able to fluidly shift between communication styles as required. Sometimes we apply the concept to different languages, or more recently by NPR to reference how race relations has evolved in the US.

The point is this: Leaders know what communication style to adopt for any given situation.  The most effective leaders I've worked with know when it's appropriate to say: "Yes, I hear your opinion on how we execute. However, this is my project, and I need you to execute the way I want."  According to the table above, this is a boss-like behavior, but ultimately leaders sometimes need to hold the reigns and drive a specific course.

Thursday, November 14, 2013

Feeding my internal narcissist

Hey folks! I've just designed this new site and implemented the matching skin on Blogger.  I think the effect is quite seamless.  On the main parts of my site (the profile/resume/contact links) I used a single page that switches between views on demand.  I like that there's no refresh switching between those elements.  All over I also used CSS fonts for all the textual elements -- the title, subtitle and in fact all the text displayed uses CSS fonts hosted by Google, which is much cooler than having to fire up Gimp to render a title.  I also used SVG for the header background and as many of the image elements as I could.  The entire thing is laid out using CSS, including the tilt to my profile pic on the profile page.  It's a wonderful time to design HTML-only pages.

What I'm not as certain about is my general design ability.  Being colorblind doesn't help, but I also don't have much background in User Experience design.

Mostly, my design process is to attempt to avoid having pop-out elements and oddball hover controls.

If you are someone with design sense who happens to stumble across this space, if you have a critique or comment and a moment to jot it down, please leave your thoughts in the comments space.


Wednesday, November 13, 2013

...On career momentum

Another good link today which addresses how to assess when you should change companies.  By Ryan Holmes I give you Stay or Go: The dilemma of when to move on in a career

I like this post, because the last words resonate with me.
And the longer you’re stuck in a position that doesn’t truly challenge you, the less likely you’ll be able to leave it.
In my view, there is no benefit to being in an un-challenging position.  The company is probably overpaying for my services, and I'm not growing my career either.  Stay too long, and any marketable skills that apply to new opportunities will rot into obsolesce.

Equally important is that there's no benefit to staying in a job where the challenges are insurmountable.

It's a Goldilocks problem -- we must be allowed to move, to make progress, to challenge but not be stopped to grow as individuals and to grow as value creators.  We have to find a place that needs us as much as we need it.

AWS Workspaces - Desktop in the cloud

This is very cool.  AWS now allows you to host a cloud desktop environment.  This is one step closer to Bob Cringely's recent prediction (and not so recent predictions) of obsolete desktops.  I will definitely be thinking about this when my next desktop update cycle hits, especially if we can start to figure out how to deal with peripheral devices like printers, USB drives, camera flash memory and largish storage (e.g. for those photos).

Update: Cringely picked up on this too, for his pet application Mainframe2.

Friday, November 8, 2013


This is a test, it is only a test.  If this were a real blog message, it would have content worth reading (or at least worth writing).