TheHackerCIO [TheH4ck3rC10]

Personal Policies for achieving "The Good Life"

2018-07-18T08:22:00.003-07:00

Good Life Policies ... This is only one.

Maybe a series will come out of it.

The policy is: Unplug for the weekend. Always. Recently, TheHackerCIO got pulled into a client's production support. When a competence vacuum develops, and believe me, this happens a *lot*, a production degradation or outage tends to suck good people into the support call. And that is precisely what happened at this client. It was all right with me, because I was authorized to bill whatever hours I worked. And when the contract ended, due to budget & contractual considerations, one of my colleagues told me the discussion centered around, "What will we do without <<TheHackerCIO>>? He's always there, whenever there's a problem?" Well, of course, they used my real name!

But it was *after* this client that I realized I was checking and answering email late at night and answering calls on the weekend for a non-production-support client. And what made it worse was that I was *not* being compensated for this exercise in "Going the Extra Mile."

So I quit. I "just said No." I established the "Unplug After Hours and on Weekends" policy. It was easy. On Friday I put in an autoresponder message on my email client, to inform people that:

"I am not on the call rotation for support this weekend, and I will be unavailable for electronic communications. I will consider your email first thing Monday morning. For urgent matters please contact my supervisor johnny.useless@somecompany.com"

Mind you, I have no idea who actually *would* be on the call rotation. This contract didn't really involve production support, lol! So the statements above are entirely true! I recorded a similar message on my cell phone:

"I am not on call rotation for support this weekend, and I expect little to no cellphone coverage. Please leave a message if you wish a response on Monday, or for urgent matters contact Johnny Useless at <number-redacted>."

Then, that weekend, I didn't check my work email. Nor did I pick up any work calls. I let 'em all go to voicemail. After a week or two, I've never been troubled again.

I'm now far more rested and refreshed each weekend for the coming week. I even started applying this policy to my after hours email. If you don't set boundaries, people will continue taking. And taking. Until nothing is left. I will always be available for after hours work for a client...

So long as they pay for it ...

I Remain,

TheHackerCIO

Why should I be connected to work if I'm not getting compensated for it?

Why Resume Updating Is SO important

2018-07-17T16:10:00.001-07:00

This is not Simon Says. It's TheHackerCIO says. And one thing he says is that resume updating is of crucial importance to your career. Don't take it lightly. And don't do it hastily. Let's see why ...

Last week I listed 4 benefits to the principle: "always be looking for that next job." They were:

1. You need to keep your interviewing skills fresh, and having at least one interview per quarter forces you to.
2. You need to keep your resume up to date, and this makes you do it.
3. You have to review technical material in order to be on the top of your game for an interview. Review is always good. And part of career self-development.
4. Knowing that You have a quarterly quota keeps you looking at industry trends, such as whether an enterprise architect is a thing of the past. (see yesterday's blog posting!)

...and the question was this: why should #2 be higher than #3?

Why in the world would resume writing be nearly as important as interviewing?

The reason is that they are reciprocally interdependent on each other. They are symbiotically related. One cannot interview properly without having updated the resume. The resume, in turn is informed and focused by interviewing experiences. But as with most symbiotic relationships, there is a dominant member. When you see Mr. Shark, you know he's the dominant member & the Remora ... well he might be helping out a little, cleaning house, so to speak, but mostly he's there to get dinner. The same thing is true of resume writing. It might be even more important than interviewing practice -- at least in your case!

Now in *my* personal case, I *already* spend a lot of time writing my resumes and don't need any improvement in that area. I'm already a world-class writer. And thinker. And this helps a lot with my resume writing. I've got cites, for instance, from McGraw Hill to prove it: not that I need to prove it. But I always back up what I say. That's part of the "More honesty than you want" principle, closely adhered to by TheHackerCIO.

In my case, where I don't do so well is in interviewing. This too comes from the "More honesty than you want" principle. But that is a posting for another day. I can at least mitigate things a bit by doing more interviews.

But before you do an interview, you need to reflect on your whole career in the context of this particular job description. And then begin revising. Editing. Probably rewriting the whole thing. And after you get done you ought to know 3-7 stories about how uniquely capable you are for this role; or how you would approach it. These are going to be key to work into the coming interview.

You also use that material to set the stage for the interview: by writing the cover letter. This should be done after you have spent a good long while reflecting on your whole career and rewriting the totality of the resume. For me, this took a full day. Really, to properly do this takes longer, but normally you can put off a headhunter for one day, and promise to get the resume out by first thing in the morning.

So do that. In fact, do it now!!!

I Leave off Here .... To Be Continued .... By ...

TheHackerCIO

Searching For A Decent Job ...

2018-07-13T10:56:00.001-07:00

Always looking.

TheHackerCIO is looking for a decent job.

Always.

TheHackerCIO just applied for another job. I'm not really in need of a job. I've got plenty of work. Too much work, in fact. But one of my Heros has convinced me, with ample reason, that I should *always* be in search of work. The economy is supposed to be "roaring" right now, if you listen to Fox. But it was fine and wonderful if you listened to the other side of the fence under the previous administrations. But everyone old enough to remember 9/11 knows that the economy has never been "roaring" since. So you have to protect yourself.

My hero spends a couple of hours a day looking for new opportunities! My resolution is not so strong. I only target one per quarter. My rationale is this, now arranged from most to least important.

1. I need to keep my interviewing skills fresh, and having at least one interview per quarter forces me to.
2. I need to keep my resume up to date, and this makes me do it.
3. I have to review technical material in order to be on the top of my game for an interview. Review is always good. And part of career self-development.
4. Knowing that I have a quarterly quota keeps me looking at industry trends, such as whether an enterprise architect is a thing of the past. (see yesterday's blog posting!)

As a bonus to the active readers from the fans who follow TheHackerCIO, if anyone can figure out why #2 is more important (to me) than #3 -- the *reason*, that is, I'll give you a "shout out" in Monday's followup posting. email me at: thehackercio at gmail dot com.

:-)

So I've presented 5 reasons to be always on the look-out for a new job, when you add protecting yourself in an eternally crappy economy to the 4 personal development benefits. It's a pretty compelling case! Overwhelmingly so, actually.

But I saved the best reason for last. It's like your dessert.

It's pretty cynical, I suppose.

As a clue to why I say this ... the image at the top of this post shows a statue of Diogenes the Cynic. He always carries a lamp. Because he's said to have always been "looking for an honest man." He should have met me! I would have told him more truth than he wanted to know -- especially about cynicism. But cynicism is a topic for another day ...

Getting back to work, and looking for it ... and the reason to always do it ...

Frankly, .....

Jobs suck.

It's not that work *has* to suck. Work *can* be good, challenging, fun, and satisfying.

It's not that co-workers *have* to suck. They *can* be intelligent, comprehensible, helpful, and dependable.

It's not that management *has* to suck. Wait, I'm not sure about that one ...

But we all know that (unless you're super lucky) the job you're in right now DOES suck. The work sucks, the people suck, and the managers suck.

But you can't resign yourself to that! To do so, is to give up on life. As Steve Jobs put it in his commencement speech:

You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.

I think I've been fairly lucky to be able to recall a few times (maybe three or four years) in my career where I was able to do what I loved and do a great job at it. And I loved it. That time is not now. In fact, that time has not been around for far too many years. This, then, is the MOST COMPELLING reason to NEVER STOP LOOKING for a job. Yeah, I shouted that. It needed shouting.

Don't settle.

Never stop looking for your next job.

I remain,

TheHackerCIO

The Enterprise Architect Is Dead ... Long Live the Enterprise Architect

2018-07-12T21:39:00.000-07:00

I got pinged by a headhunter this week.

They are seeking an Enterprise Architect.

Since I recently vowed to *always* look for a new job, I told them "Sure! I'm interested for the right opportunity and compensation." Then I promised to get an updated resume out by tomorrow. After that, I grabbed a cup of ...

... my favorite beverage during work hours ...

Then I called up my friend and colleague, whose name has been changed to protect his innocence, "T. Mountain", who used to work as an Enterprise Architect for a 6 Billion dollar a year company. And a darn good one, I might add, based upon my personal experience and knowledge of his experience, attainments and manner of working. We had worked together at a brokerage firm many years back.

I called T. Mountain because I remembered that he had been laid off from, oh what the heck!, the company shouldn't be protected from the guilt of their stupidity! ... He got laid off from Lexis Nexis. When I got T Mountain on the horn, we had the following exchange...

TheHackerCIO: "So tell me, you got the Ax at Lexis right?"

T.Mountain: "Yes, ... actually they eliminated the role."

TheHackerCIO: "What did they say? Was it like, 'So we no longer have an Enterprise and therefore we have no need of an Enterprise Architecture." Or was it, "We no longer desire to pay any attention to architecture, because we'd rather be agile and not plan anything we do."

T.Mountain: "Actually, they kept Domain Architects and Solution Architects. So they just eliminated the Enterprise Architecture role.

TheHackerCIO: "What is s Domain architect?"

T.Mountain: "They handle a particular subject area domain, so they are kind of technologists who are also SMEs about some aspect of the business."

TheHackerCIO: "I see! So did they say, 'We've decided that we no longer want to have enterprise-wide integration and planning. We want to move back to where each Domain can be a separate, uncoordinated "tower," or "stovepipe," unconnected to any other system in the enterprise. We want to avoid having systems in separate groups aligned to a common strategy or business purpose?"

T.Mountain: "No, they just said they no longer required the role, but of course what you say is the natural implication of their actions."

TheHackerCIO: "I'm asking you about this partly to laugh about the Dilbertian nature of their stupidity, but also for a serious purpose. I'm applying for a contract as an EA and I thought that those kinds of roles had died. I knew you got axed."

T.Mountain: "Yes, the EA role was eclipsed for a period, but it was a brief cyclical downturn. Many of the people at LexisNexis are upset that we are now gone. And I've seen a lot of resurgence in enterprise architecture demand recently, especially in my LinkedIn searches."

TheHackerCIO: "Well, that's good to know. And of course the key to such a position is that you have to have some power as well as responsibility, or else you can't succeed.

T.Mountain: "That's right. Be sure that your boss has executive sponsorship, so that EA is actually respected and has enough power to actually deliver value. At Lexis this was not the case."

TheHackerCIO: "Of course not."

T.Mountain: "We had the Domain Architects and Solution architects ... they just ignored our direction and suggestions."

TheHackerCIO: "Of course. Thanks for your time ..."

And so, I remain .....

TheHackerCIO

Fragility of Technology

2017-02-07T09:09:00.000-08:00

Ah the delicacy of technology. I had hoped for a highly productive day today, but technology had other plans for me.

7am: I woke up, grabbed my iPhone, and checked my LinkedIn message.

It froze.

Attempts to force a restart were unsuccessful.

I "googled" other possible ways to force a restart, at which point the iPhone gave me a dark screen with a faint cycling "wait" symbol.

I found that I could force a factory reset from either the iPhone, (which option was now closed to me) or from iTunes.

So, a pot of coffee now brewing, I downloaded iTunes to install on my new ThinkPad. I recently returned to WinDoze, after a three or four happy years on a Macbook pro. I had given the beautiful Macbook Pro with Retina, still in pristine condition, to my daughter, to use at college.

iTunes failed to download: Network error. No visibility into what this could be, of course. Email was working on the laptop. Everything else seemed normal.

Repeated attempts to download varied. Some came close to successfully downloading it; others failed immediately. I got as close as 10 seconds away from a successful download.

Then I lost internet connectivity. I knew this because my browser told me so. Attempts to "repair" it through the Windows Networking utility were useless failures. I piggyback my internet off a Cable modem, so I checked the Cable TV transmission, and cable modem lights, but found nothing wrong -- no interruption in the Cable portion of the signal transmission. No light indicating signal failure.

I would have tried plugging my laptop directly into an Ethernet cable, to eliminate the Wifi router as a problem, except the new generation of lightweight laptops are not built with that purpose in mind! They are too thin, and expect only to ever be used with wifi. So you physically cannot plug them into an ethernet cable. At least not the one I have. You would need an adapter. I don't have such an adapter, anyway.

No use wasting more time, right? So, I followed the generally accepted approach to troubleshooting any and everything: I rebooted the modem.

Naturally nothing changed, so I opened a console window and forced an ipconfig /renew and an ipconfig /flushdns. Ping confirmed that I now had restored connectivity. So I tried my iTunes download again. Yet another failure to add to the list.

So, I woke up my daughter and borrowed her Mac, to get access to the iTunes. I had already wiped it clean and done a fresh install for her, but I still had an account on it. It did bother me when the message came up that it was "configuring the laptop for Apple Store," since I didn't want it configured for my account, but I was getting desperate. So without looking into the implications, I went ahead and gave it my password, and got in.

8:30am ... I attached my iPhone to the Macbook, and went into iTunes, per the web pages telling me how to factory reset my phone. A pop-up on the Macbook asked if I wanted to allow this computer to access the information on the iPhone. I did of course, so I clicked "continue" Hmmmm ... is "continue" really the right response to this question? Shouldn't it be "allow," versus "deny." Oh well ... Now I got this exact message:
"to allow access, please respond on your iPhone..."

But I'm not able to respond on my iPhone -- it's hosed. So, I have to stop this or ignore it. If I don't stop it, I can't navigate anywhere else on the window in my Macbook. So, I stop it. Now, finally, I am able to navigate where the "googled" page said I should, to File | Devices, where I should be able to force a factory reset. All sub-menu options are grayed out.

8:57am So, I've now wasted two hours attempting to fix my iPhone. I knew when I started that the chances were slim-to-none, because I'm an "experienced technologist."

I know that you, too, gentle reader, have had similar experiences. You know what I'm talking about

I deliberately documented this misadventure explicitly, and formally, to show the way in which interlocking inter-dependencies operate to hinder productivity. Technology continues layering on new capabilities, features, and options by orders of magnitude. There never seems to be any stress on making the technology more robust. So the fragility of our technology just continues to rise, even as we come to depend on it more and more. It makes for a high degree of frustration.

I Remain,

TheHackerCIO

A Fiery Death for the Workers Near You!

2017-02-03T08:06:00.001-08:00

Fire safety means never caring to save your neighbors!

TheHackerCIO recently took mandatory safety training at a Fortune-500 company. These are on-line presentations, with automatically scored answers. God forbid that you should score less than 80%! The punishment is to repeat the damn course! That's serious punishment.

Books have been written about the evils of multiple-choice testing.

This fire test was a perfect example.

No explanation is possible on a multiple-choice test. So, when faced with the question, "Which of these choices is correct," and having received a feedback score of "incorrect" for selecting that I should evacuate and that I should get as many coworkers as possible out with me, I could pretty well assume that the "correct"response was to keep my mouth shut and let them burn up.

If I had been able to add a written response as a "challenge" option, this ridiculous answer would have been corrected by one of the instructional designers. But no, no human interaction is allowed or desired. So the answer remains.

So, if there should be a fire near you be safe.

Let your neighbor die!

Safety first!

I Remain, Ever the Unsafe,

TheHackerCIO,

Bargain Basement Rockstar

2017-01-31T13:18:00.001-08:00

Reciprocity is mandatory.

Or should be!

TheHackerCIO gets Job Descriptions (JDs) all the time that list a huge laundry list of skills, qualifications, desired experience, and job responsibilities. Many times no one in the world could possibly be a master of all these. Often, it is physically impossible to meet these supposed "requirements," because the technology hasn't been in existence that long. It specially irks me when I see the desire for a "Rockstar," such as you can see here (excerpt following, but the link has the details):

A word about titles: we are calling this job opening "Full-Stack PHP Web Developer", but we welcome applications from those who consider themselves any of the following: software engineer, software architect, web developer, programmer, hacker, coder, computer scientist, devops, "ninja", "rockstar", "wizard"... etc. We had to choose one title.

Here's what TheHackerCIO tells recruiters looking for a "Rockstar."

"So you want a rockstar, it says? Now Rockstars are few in number. They aren't everywhere. And they get paid huge amounts of money for what they alone can do, right? So, what kind of unusual, eye-catching, exceptional compensation is this company offering to acquire such an extraordinary individual?

The pause is real ...

But an answer never comes ...

Usually, they say they are offering a "competitive" salary. But I don't know what that means. How about if I make a resume for you like that? I can say, for instance:

has a competitive understanding of a competitive number of technologies.
assumed a competitive level of responsibility and leadership.
competitive communications ability.
has a competitive level of interest in "working together as a team player."

That's what someone should expect if they want to offer a "competitive salary."

Then the phone screening can happen, we can imagine it...

Q: On a scale of 1-10, what is your skill with Java?
A: Competitive, like your salary.

Q: How many years of experience do you have with Cassandra?
A: a competitive number of years, like your salary.

Why do you think you can get a Rockstar at bargain basement prices? I don't think working for your company will be like doing a charity event, will it?!!!

You see, reciprocity is (or should be) mandatory. If companies can't hire people without demanding specific, concrete, numerical measures of experience, why do they think they can evade telling how many dollars they are willing to pay to get this experience?

Shouldn't they clearly offer a range of money? "In order to get the best candidates, and as an indicator of how serious we are about seeing truely Senior, hard-working, high quality applicants, who are in high-demand from other purchasers of their services ... we are offering in the range of $160,000 - $170,000 p.a. plus insurance, 4 weeks of paid vacation, etc."

A little reciprocity please, companies. A little reciprocity, please, recruiters!

I Remain,

TheHackerCIO

Fired and Proud Of It!!!

2017-01-27T15:56:00.000-08:00

Only Keep a Job that SHOULD be Kept!!!

At the Tech Job Fair in Los Angeles yesterday, TheHackerCIO ran into several wonderful colleagues. I didn't want a job. I have too much work! But I did want to know more about what new startups were hiring, and where they were located. I managed to survey almost all the smaller Startups, milling among thousands of people. I was told that over 13,000 people, in total, attended. I can believe it.

One of the best colleagues to run into, a fellow Geeky Book Club member, told me about his "consulting woes." He was concerned that he might have "burned some bridges" in the last few contracts, because his services "were no longer required." In other words, he got the ax. It's pretty easy to step on toes as a consultant. He wanted to do things right. The client wasn't so interested in that. The client didn't keep him around. Now, he feared, he wouldn't be able to go back into that institution.

TheHackerCIO comforted him. You can go back all you want!!! When you do nothing wrong, have no fear about getting the ax! It's a badge of honor! Plus, you're better off without such a client. (Not everyone deserves a good worker!). I told him my own story about a recent client I "lost," which I was proud of. He had two in the last few years. I matched him two for two, also in the last few years. And I have nothing but pride for these "losses." Interestingly, both of these "losses" came from cowards.

In one case, I actually had an inkling that things were wrong. I got that idea because the client-coward didn't want to deal with me directly. He asked the agent I was working through to tell me, and he let it slip before I was out the door. So, I "accidentally" (heh ... heh) turned on my cell phone recorder, and slipped it into my shirt pocket. Thus fortified with a verbatim recording in-progress, I sought out the coward and discussed the situation with him directly. TheHackerCIO is not a coward. The result was a recorded transcript of the greatest firing ever! At some point I'll transcribe it word for word, but for now I'll mention the best part, emblazoned in my memory. Mr Coward said, and I quote, "You are a highly productive person, and you are never going to be happy here. This place is a cluster-f**k"

How can you argue with that?

I tried to offer to help un-cluster-f**k the place, but that wasn't of interest. He was one of the cluster-f**kers!

In the other case, I was required to teach junior staff about Cassandra, a NoSql database, which I happen to be pretty knowledgeable about. In session one, I noticed that one "participant," let's call him Moh Foh, for short, was glued to his laptop, and not learning much, if anything. In Session two, I needed to recap what had been covered and see where to go. So I made it a fun exercise. "Lets make this fun, something like a game show," I suggested. I quizzed them round-robin about failure scenarios, seeing if they knew what would happen under various conditions Two of my "players" did fine! If they knew the answer, they got praise. If not, I quickly helped them out with hints or an answer. Then I asked them a follow up. They were enjoying the exercise, and we were all making good progress.

Everyone except Moh Foh, that is. There he was, glued once again to his laptop. He had nothing but a blank look to offer when I asked any question. So I said, gently, " Can you close that laptop?" He didn't, but he postured that he was going to pay attention now. So I described the question for him again, on the white board, and turned back for his answer. Once again, MohFoh was glued to his laptop screen. He couldn't even pull away when he knew I was re-describing the question explicitly and personally for him! The rudeness, disrespect-of-a-colleague, unprofessional-ism, and bovine stolid indifference were almost beyond belief. But I managed to remain good humored, and I said, "Come on now, close that laptop. Close! Close!" and he did. For a third time, I returned to the white board and repeated his scenario/question. When I looked back at him can you guess what he was doing?

You're right! Moh Foh was now glued to his cell phone, and had no idea how to even attempt to answer the question. So I said, "Really?" At that point, he said, "I have to leave," and bailed out. A little bit later the coward-in-charge asked the agency to declare me persona non grata.

Later on, before I was cowardly axed, I attempted to patch things over with Moh Foh. I told him that if he couldn't pay attention, I couldn't teach him. He said that they had to "multitask" around there. I told him that it's been scientifically proven that you *can't* multi-task. All you can do is a crappy job at many things. And in his case, he wasn't even able to pretend to do even a crappy job of learning Cassandra while he monitored whatever he was monitoring. If he actually was, and wasn't Facebooking.

I'm so proud of being axed for this that I'd like to put it on my resume! It's a badge of honor. A possible entry text: "Accomplished teaching basics of Cassandra to staff. Pleasantly, but firmly, refused to accept disrespectful inattention and "I don't care" attitude from students with a junior-high-level mentality." Yeah, I doubt I can work it into my resume, because I hope to never do it again. It's not a target for the future. But I'm plenty proud of it.

Not every job should be kept. A client like this needs to find someone who will pretend to teach those who are completely uninterested or unable to learn.

I Remain,

TheHackerCIO

Yesterday Was The Greatest Day of My Life

2016-07-21T23:45:00.002-07:00

Biting Like a Pit Bull, twice [AKA Code Complete ch. 19]

2016-07-13T23:01:00.002-07:00

No, it's not TheHackerCIO biting you like a Pit Bull.

The biting involved refers to problem areas found in the book. We'll get to that in a moment.

Let's back up here a bit. This blog is multi-purpose. One purpose is to record interesting things learned and discussed in the many technology Meetups I regularly attend. At the same time, since I'm both a code hacker AND a CIO type, I need to strike a balance so that I'm not too technical only with these posts. I don't want to scare off people who are interested in my views on outsourcing ???, for instance, or the 10x engineer???. The solution I've hit upon is to start general interest when I'm recording Meetup Notes, as I am here and now, and then gradually move more technical to the actual comments on the book. You can quit if and when things get too technical or specific.

As I said, this particular blog post, always on Wednesdays, is dedicated to the previous evening's Meetup Notes. On Tuesday evenings, for about a decade, TheHackerCIO has enjoyed a Meetup called DevTalkLA. It's a book club. For techies! What makes it nice is that I've known the core members for this whole time. They are both friends and colleagues. And they are excellent technologists. The discussion is always good, always helpful. Even if the book we democratically select doesn't live up to expectations, we find ways to weave in work-related questions, or meta-criticism on the problem of technical writing, or something. So we make every sessions worthwhile. And so, while I'm at it here, let me give a shout-out to both Ken Dempster for hosting it for so long, and to Sony for graciously allowing us the use of their facilities.

If you want to join, I'd encourage it. We love new blood. And feel free to come mid-book. We allow backing up.

The current book of interest in called Code Complete, by Steve McConnell. Last night we covered chapter 19, but remember ... that allows anything prior to chapter 19 to be covered. :-)

There were two particular problem areas that bothered me in this chapter. This is where we're going to "bite like a pit bull." For now, I'm too far behind on blogging, so I'll update this page to explain further, probably tomorrow. But for now, I need to "book" a place on Wednesday for this DevTalkLA Meetup review. So, I'm about to hit "Publish."

====================Discussion Notes===================================

p. 434 - Ken really likes to pull expressions out into a method, with a really good name. Even if not complicated, because it makes it more readable.

George on the other hand argues that locality of reference makes it more of a pain: you have to look it up, and that's an extra overhead.

Ken's take was the the good name eliminates the need to look it up. Unless of course you think you have a problem with it, and then it's easy enough to do.

TheHackerCIO agrees with Ken. Pull em out. I'd like to incorporate this notion of multiple levels of condensation into a new language, but that's a blog topic for another day.

p.438 - short circuit operator ... is this wrong? Maybe I'm cynical

p.441 - Ken raised the idea of the null object.

p. 446 - what *is* a side effect? we argued a bit about this. I'll post my argument and we'll discuss further in another blog posting. Basically, I'm not convinced that this is an example of a side-effect. I want to bite like a pitbull on this one, because I've had a bad feeling about this usage for a long, long time.

Ken saw an abstract enum the other day. I don't see it. Isn't an enum supposed to be essentially a literal? He promised to post it.

Another way Ken likes to roll his own enum is with a map: you know, a key value pair. then he can just look them up.

George noted how happy he was that you can use a String in a Case statement. TheHackerCIO noted that the whole Java world breathed a sigh of collective relief at the eventual capitulation to this excellent notion.

========================================================================

I Remain,

TheHackerCIO

A Bucket List Item: SICP

2016-07-12T02:40:00.002-07:00

The Wizard Book!!!

Yes, The Wizard book.

TheHackerCIO finally got to go to this Meetup: Computer Science Reading Group. It's based on reading the classics of Computer Science, and working actively on solving the problems found therein.

At present, they are working through the classic book, available free online!, by Abelson and Sussman, Structure and Interpretation of Computer Programs. Commonly "initialized" as SICP, this book is a LISP based advanced beginners "introduction" to programming languages. Instead of focusing on the mechanics of languages, the focus is on the abstractions used within computer science.

You must have heard of this book! It's a classic! A.K.A., "The Wizard Book," from it's cover, this book is written by MIT professors and became for many many years the basis of a class at MIT. Thanks to the new MOOC trend, you can now see/take this class for yourself here. Go on! I recommend it!

The LISP of choice for the Meetup is Chicken Scheme, available on the MAC through a Homebrew install. Or, if your a building kind of guy, you can get the source code here. I was going to build it, but I had a client MacbookPro without XCODE loaded. And building from source code required GNU Make, which in turn required a Homebrew install! So, I gave in, and put up homebrew, to save time. Then it was a simple command to install Chicken-scheme:
brew intstall chicken

you also want some "eggs," apparently some kind of module or library system. In this case, you want an sicp "egg," so you should issue:
chicken-install sicp

Then you invoke the Chicken-scheme by entering this command:
csi

Which puts you into the chicken scheme interpreter or REPL prompt: Next you load the "egg" by this:
(use sicp)

You'll see messages that libraries were loaded. Finally, the acid test is the simple Functional "Hello World" equivalent:
(+ 2 2)

Which for those of you having some Functional style experience, is the way that you add two and two in LISP. You should get the answer of four, naturally.

The previously mentioned wiki has a special place to then "get started," so that's a good place to do just that. Documentation is also available here.

Three or four of the attendees had to get installed, so we spent a good bit of time going through the above steps.

Then, Mac pointed us to an interesting article on building a scheme from scratch, by Peter Michaux. There was also mention about a special github, where the source for special things to be used in the book is kept. I'm not that clear on what exactly this was, but the account is here.

Then Frankie discussed and presented his attempts to solve problem 5.52, a garbage collector in C. Apparently the book structure, toward the end requires you to implement your own lisp in lisp, and then in C.

All in all, this was a wonderful meetup! For many years this book has been on my "bucket list," and now I have an excuse to work through it in the company of like-minded individuals. It doesn't get any better than that!

I remain,

TheHackerCIO

Spam, Hideous Spam

2016-01-04T16:27:00.000-08:00

Spam and Bitter-Rancor I sing, O Muse ...

TheHackerCIO hasn't had a great experience with comments on any web posting. Here is why he hates trainers from X ...

A while back I posted why-hackers-hate-headhunters, which received this comment:

========original comment text follows ====================
Jhon Mick November 16, 2015 at 3:27 AM <>

Learning new technology would give oneself a true confidence in the current emerging Information Technology domain. With the knowledge of big data the most magnificent cloud computing technology one can go the peek of data processing. As there is a drastic improvement in this field everyone are showing much interest in pursuing this technology. Your content tells the same about evolving technology. Thanks for sharing this.

Big Data Hadoop Training in Chennai
=============================================================

To which I replied:

Note that the comment above is pure, hideous spam, in the newer form (i.e., that of comments rather than email) Observe that there is no shred of relevance to the subject or theme of this posting. Clearly "Jhon Mick" googled Hadoop, which is mentioned here and then felt perfectly free to post meaningless buzzword stew to try to get people to look into his Big Data Hadoop Training in Chennai. That earns them a big roasting, from TheHackerCIO. And probaly, the comment will be deleted, so I preserve it here, without the repulsive link, which I certainly don't want crawled.

So not only does TheHackerCIO hate headhunters, but he also has to hate email trawlers who couch their spam in the form of supposed comments. These people really need to get a life. Can somebody please train these trainers on How to be a Decent Person?

I Remain,

TheHackerCIO

Making Assholes Accountable!

2015-06-11T17:14:00.001-07:00

Life is way too short to put up with assholes. Whether at work or at home, you really need to "just say no" to them. All of them.

TheHackerCIO just the other day told a co-worker, "I just can't believe that every new client I visit & open up their Microsoft products, the UI is completely different."

I mean ..... really? Do we really need a multi-page-click "user-experience" in order to move from a document to print it, and then move back to the document? This is a new and improved experience? For those not yet blessed, I speak of "Microsoft 365."

But this collage was an asshole.

His reply was, "If you find dealing with change problematic, then you're going to have problems here at <Company-Name-Deleted-To-Protect-The-Assholes>." What a dick. Luckily, I don't have to deal with that dick any more!

It's important to hold this kind of asshole accountable for his asshole-hood, but I'm still working out the right way to do it. If I'm lucky, he'll read this one day, realize that he's the asshole, and the connections will fall into place.

Here's another prime example of assholity: A highly respected colleague recently interview with a major company for an Enterprise Architecture position. The company never got back to him -- neither the HR department, nor the hiring manager. This is a sample of the right way to hold this kind of asshole accountable:

Now here's where it really got bad. This hiring manager, who lives in another State, utterly defaulted on his obligation to "get back to the recruiter" with feedback. Now, over a month later, I still haven't heard one word either way about anything. The recruiter was completely mystified by the manager's complete lack of responsiveness. The recruiter, who was quite good, had attempted to confirm the face-to-face interview details, and was unable to -- he never received *any* response from this hiring-manager. No confirmation. No feedback. Nothing! Very unprofessional. Molina should fire the hiring-manager.

Frankly, anyone who takes up the time of someone in an interview has a moral obligation to give a response with feedback to that person in a timely manner. It's an implicit contract that underlies the interview process. This hiring-manager-who-needs-firing not only defaulted on this obligation, but actually lied to me. He stated to my face that he would get back to the recruiter with his feedback. He never did.

On a personal level, I feel that I had a lucky escape. The lack of organization (about who would interview me), coupled with the lack of responsiveness to email and phone calls, and co-workers with a poor grasp of English -- all this points to that work environment being the kind of place I'd rather not spend my life trying to fix. Give this "shop" a "miss"! That would be my advice.

Glassdoor is wonderful and a great way to hold hiring managers accountable for their interviewing.

So, figure out ways to get rid of the assholes you deal with. And call them to account for it. Because life is too short. Way too short.

I Remain,

TheHackerCIO

Uncle Bob at Ticketmaster

2015-05-23T15:40:00.001-07:00

Last Tuesday, "Uncle Bob" Martin spoke live at Ticketmaster. [Thanks, again, to Jody Mulkey for organizing an excellent event!]

He spoke, unsurprisingly, on Test Driven Development (TDD).

TheHackerCIO loved the hat he wore! Someone brought it -- a professor from Loyola, I believe. It was a stitched together amalgamation of three baseball caps, so that one faced forward and two others flapped off on either side of the ears. The three caps were each Red, Green, and Blue -- the TDD colors! So, as Uncle Bob demonstrated TDD on-screen, and wrote his first failing test, and his IDE switched colors from JUnit to Red, he placed the Red cap forward. Then he cycled through fixing the code, and when he got to green, the Green Cap went forward. As he refactored, he then physically went blue. It was pretty cool. I snapped a shot, but he was pretty far away.

One of the more interesting points he made was an analogy with the accounting profession. He posed the question to the audience ... "What other group of people manipulate a set of symbols with such a level of precision that every tiny error must absolutely be corrected. [TheHackerCIO: my words, his idea]" And the audience came up with "accounting." Uncle Bob's take is that double-entry bookkeeping is the technology invented to deal with this condition. Invented in the Renaissance, double-entry bookkeeping only achieved universal acceptance in every country in something like 1945.

According to Uncle Bob, TDD is double-entry bookkeeping applied to code.

And he predicts that it will eventually sweep the world.

Watch the video of the event here:

If you like what you saw with Uncle Bob, DevTalkLA, a Westside Meetup will begin working through his book Clean Code (pictured above), starting this coming Tuesday. You can find out more, and even attend -- we love guests -- by clicking here.

I Remain,

TheHackerCIO

The Longer the CV, The Better

2015-01-07T10:17:00.002-08:00

[for part 1 of this series, click here]

As we said, the prevailing Whiz-dumb thinks a long CV sucks.

But this is wrong on several fronts.

To see a real CV, and simply to demonstrate that TheHackerCIO never "Makes Shit Up", please click here, to see a real CV. This is Donald Knuth's example. Academics understand what makes up a real CV. They live and die by them. They are an essential tool.

Now, is Donald Knuth an idiot for having a 40 page CV?

Or, are these Recruitment Pundits who tell us to keep it down to one page missing something?

Short answer: it's the pundits who are wrong.

Yes, Donald Knuth needs a CV. A long one! He needs to catalog everything he has done in the course of his career. Every book, video, audio, and paper he has written needs to be stated, whether refereed or not. That's hundreds of papers!

Now, maybe you're saying at this point, "But I'm not an academic. I haven't written three or four hundred papers. I have no need to itemize all of this." And I'm sure that's probably true. But if you're a senior technologist, you have worked on hundreds of projects. And every single one indicates your unique skills, learned context, and achievements. All of that has contributed to make you the technologist you are. Why should it be ignored or forgotten? Is what contributed to making you the technologist you are now unimportant?

Far from it.

I know that this series is starting out as a bit of a teaser, but bear with me ...

Next time, we'll look at further reasons why all this detail is MANDATORY, for your own personal career development.

Until then, I Remain,

TheHackerCIO

The CV for Americans

2015-01-06T14:41:00.001-08:00

Americans don't write CVs. They write a "Resume." Especially technology professionals. In fact, the conventional, generally-accepted, "consensus," Whiz-Dumb holds that a resume, or even a CV should be one or, at most, two pages! For example see this, and that. But this is a huge mistake, and a long, detailed CV is important for everyone.

The essence of the brevity argument is that recruiters and hiring managers are too dumb or lazy to read much. They phrase it in euphemisms, but that's what they mean. For example, in the article above, they spoke of these inDUHviduals having "short attention spans." In other words, they are mental cripples, or too lazy to read more than one page.

TheHackerCIO begs to differ. I write what I want. What the reader does with it is his business and his problem. I can accommodate the recruiter's and manager's laziness, stupidity, and brain deficit by writing in the "reverse pyramid style" of the newspaper writer, where everything important comes first, and less and less important content follows later. In short, the reverse-chronology ordering tactic fits perfectly. I start with my most recent experience and work backwards.

But these are issues of scope and arrangement. This is all just formatting!

The more important issues are personal and substantive.

Since many readers don't know what a CV is, and almost no-one knows its meaning, advantages, and utility, I'm going to start off the year by explaining a bit about the good old Curriculum Vitae, why you need a long, detailed one, and the benefits that come from the exercise of producing one.

This is an excellent time to work with me through this exercise, so you can be ready in the new year for any new job searches that may arise. Or, just be ready so that you can take your career to the next level.

We'll see why the CV is crucial to this ..... in the next post.

I Remain,

TheHackerCIO

Userless User Stories

2014-10-03T15:32:00.002-07:00

"The Struggle" is real, says TheHackerCIO as he attempts to do "Agile" development in yet another pathological Behemoth corporation.

Central to the idea of the Agile development approach is to drive everything from "User Stories." The point of this is to get Users driving development. To get Users needs, desires, and requirements into the forefront of developer's attention.

Supposedly, TheHackerCIO has been working in "Agile" environments for several years. But he would love to actually use Agile! Just once. Is that asking too much?

Although they claim to be agile environments, the Pathological Behemoth corporation just forces the round-peg of Waterfall into the square-hole of Agile and let's the chips fall where they may.

For instance, I've seen "User Stories" in the Product Backlog which contained references to the project phase! There are no "phases" in an Agile development. But such is the state of the industry.

The latest outrage is User Stories where there is no actual user! These user stories start off "As a developer I want to ..." and end with so much BS about what non-functional requirement needs to be attained. For example, "As a perfomance engineer, I want to make sure that cache access is less than 10 milliseconds per request."

"As a developer ..."
"As a tester ..."
"As a deployment coordinator ..."
"As a production support resource ..."

Where the hell is the user?

If anyone doubts the stupidity of this kind of approach, I have a challenge for them! Take up this "user story" from my product backlog and start a sprint on it. Hell, I'll give you two weeks. Then we can look at your code.

On this same subject I ran across another blogger who objects. I'm not surprised, since anyone sane would object. But I point my readers to it here.

I Remain,

TheHackerCIO

Zero to One

2014-10-02T14:52:00.000-07:00

Last night Peter Thiel plugged his new book.

It looks amazing!

The lecture was great. TheHackerCIO found Thiel in person to be as stimulating as he is in the many videos available interviewing him, such as on TechCrunch.

I highly recommend getting this book, although I've only made it through the first two chapters.

I think this is the only time I've ever recommended a book without having completed reading it. It's worth reading just for the Preface and Chapter One!

Peter defines technology as "doing more with less." In the lecture he expanded on this, pointing out that we have a big problem with our government at present, because every year it spends more money and get's the same or worse results -- for instance in Education. Which means that government (as it stands at present) is doing less with more. And this was not the case back even in the 1960s. He pointed out in the lecture that we could attack a problem like landing on the Moon back then. We could even declare war on Cancer. Today, no one can or will declare war on Alzheimers. It wouldn't poll well, and couldn't happen. We're unwilling to take on big challenges.

Peter says that "humans are distinguished from other species by our ability to work miracles. We call these miracles *technology*."

Again, get the book. Get it quick. And I'll try to post a more complete review when I've read it fully.

In the meantime, I Remain,

TheHackerCIO

DevTalkLA Does an About Face

2014-09-10T12:05:00.001-07:00

DevTalkLA, that Geeky Book Club started a new one last night. Pictured above, we began discussing About Face. This is the new 4th edition of a "classic" which has been around for two decades. This latest release came on September 2nd, and includes mobile devices!

Mobile is crucial for user experience! So this promises to be a very important book.

TheHackerCIO doesn't specifically focus on User Experience (U/X) as a sole pursuit. But he has to wear every hat in the wardrobe, so adding in knowledge about U/X and IxD (Interactive Experience Design) is a welcome addition. It adds to the arsenal.

We had a lot of new blood at the Meetup. 24 people RSVPed, but of course only 12 showed, making for a 50% Unreliability Factor. It's always good to note how flaky, irresponsible, undependable and unreliable people are. It's an important index for life. In this case, 50% of respondents actually had the politeness and follow-through to keep their commitment. TheHackerCIO follows this principle, "Always call out bad behavior." You don't want that to go unremarked upon. Ideally you'd like to see it go away. Following through on your RSVP allows a Meetup organizer to get a room of the correct size. If all 24 had showed, we would have needed the larger room. It also allows the organizer to get food or refreshments for the Meetup. I mention this just to indicate that RSVPs have a *reason*. And it's only common courtesy to RSVP if you're going and stick to it.

With over 50% of attendees being first-timers, the Fearless Leader spent a good deal of time giving everyone an overview of DevTalkLA: how we've been continuously discussing technology books for 15 years or more, how we select the books (by vote), and the "bidding" system we use to determine who goes next on offering a comment/question/problem or issue to discuss.

As usual, the discussion was wonderful. I hope we see these newcomers return next week!

We began discussing the introductions, with the interesting point that designing behavior is a totally new concept. Products have been designed, but in a very static sense. The form of a product has been designed. Even the content has been designed. But with computer technology, we now have an additional element of behavior to consider and design.

We were greatly missing one of our old-timers for this book. He has to sit it out for personal reasons. He was always such a helpful addition to the group because he came it with Post-It-Tabs showing clearly every next comment he would raise, and in the absence of others having read the book, we could depend on him to drive the discussion. Since this book was a new release, I made sure that I did a similarly thorough job, so that we would have a very full and helpful discussion for the kick-off session.

On page xxii and following: I noted that there was some confusion. First they questioned whether an experience could be designed. So instead the book authors "have choosen Moggridges's term 'interaction design' to denote the kind of design this book describes." This statement in isolation isn't confusing, but the following paragraph stated that "we feel the term *user experience design* is most applicable." So the question is, WTF? Is this book going to use the term "interaction design" or "user experience design," or both? If they are using both, when will they be employed and why the need for both term? It's not crucially important, but it raised issues for me, and no-one else was able to offer any insight.

TheHackerCIO has lot's to say, but this is running too long already. So, I'll leave this ...

To Be Continued ...

TheHackerCIO

The Alleged Importance of Communications

2014-08-21T17:16:00.002-07:00

On every side you hear the cries of people claiming that communication is essential for the job market. If you don't believe me, Google it. But since I always supply some indication of support for my opinions, you can look at this Forbes article, where number one on the list is "Top Notch Communication Skills."

And TheHackerCIO agrees with Forbes! Communication Skills is crucial for project and career success.

Why, then, does the title to this article include the word "alleged?"

Because I seriously question the valuation companies give to communication skills. If it were high on their list, I would not attend meeting after meeting where I strained to puzzle out every word from a strong accent. I'm not a Xenophobe, by the way. I was quite happy to have good hard workers from foreign countries on my project. In the UK, I noted & discussed with my wife how it was the foreigners who stayed with me late into the night to get a presentation deliverable done for a tough deadline. The Brits went home. The Union Shop representative left exactly at quitting time (6pm).

For you Americans, that wasn't a slip. Yes, a lot of companies in the UK are Union Shops. Their technology professionals are unionized. And they have a Union Rep, to make sure that no exploitation of the working class -- if, indeed, programmers are the working class -- takes place! And the Union is the kind of place where Stalin is still viewed rather sympathetically. I'm pretty sure it would be easy to get a stirring defense of him out of some of the denizens of the Union facility. But we've gone on a rabbit trail here. It was fun, and TheHackerCIO likes to open up people's perspectives by hitting them with conditions in other places, so it was useful. But now we need to get back to the problem of communication.

As I said, I'm happy to have foreign workers on a project & I've had very positive experience with their work-ethic. But over the years I've found that poorer and poorer communicators have come into the work force. At present, I have to ask people to repeat themselves in virtually every meeting. The other day I was distance chatting with a foreign colleague. I was amazed to hear him complain about exactly the same thing! I can understand him at the 100% level, but he can't even understand most of his fellow countrymen!

This could not have happened if companies really valued communications. The proof of what you value lies in the results you achieve and tolerate.

Outsourcing, too, is an example of a wide-spread practice which impedes communications. I could list a half dozen reasons:
* time zone differences
* cultural differences between differing countries
* language differences & accent problems
* corporate divisions resulting in company cultural differences
* lack of non-verbal clues
* inability to "just drop in" at someone's desk

I bet, if I tried I could come up with another dozen. Again, if companies *really* valued communications ability, they would avoid outsourcing like the plague. That is not what they do. There has been a slight pull-back in the management world. But it's mostly like a stupid child pulling his hand back from the stove after being burned for the twentieth time.

Just this year I overheard one client conversation about their outsourcing effort. With hundreds of cookie-cutter deliverables coming from the off-shore team, EVERY ONE was unusable! Just like what I've seen. But what is far more remarkable, is that this client's senior management team were *from* the country where the outsourcing took place. They visited the offshore team regularly. They were in constant contact and direct personal oversight, often in-person. Yet they were unable to avoid a debacle of this nature. That's because communications is hard. And any impediment AT ALL has to be stripped out of the way.

But that's assuming that you value ... and I do mean value ... *truly* value .... communications skills.

I Remain,

TheHackerCIO

Stoking the Furnace

2014-08-20T17:14:00.002-07:00

Reading about writing, lately, TheHackerCIO came across a metaphor. The writing is like a blast furnace. It takes many weeks to heat one, to get it ready for making Steel. So too, in writing, or blogging, one must prepare the mind. And the process takes time.

Stay tuned...

For TheHackerCIO is stoking up the fires again, for the coming Fall.

I've been asked questions about technology careers ...

I've been asked questions about blogging ...

I've had a new client, crazier than most ...

I've had interesting discussions about the crazy clients we shuffle back and forth between ...

And I'm particularly interested in conceptual integrity & revisiting Frederick Brooks, that author of timeless classics ...

As well as rethinking my own career and how to rethink such a thing ...

Not to mention the need to achieve what YOU want from the job you work at.

So, stay tuned for more from TheHackerCIO, coming soon ....

I Remain,

TheHackerCIO

A Startup that Remains So is a Failure

2014-05-22T08:51:00.000-07:00

VC funded Startups always kick out the Founders. It's regarded as a measure of success. And, frankly, sometimes they need to be kicked out. But, recently, TheHackerCIO found this presentation. It not only explains, reasonably, *why* founders need to go. It explains, concisely and cogently, why Startups must not remain Startups. To remain a Startup, is to Fail.

It also focuses on the innovation occurring in the lean side of Startup financing. That is to say, in places like Y-Combinator, and other accelerators. A good part of that innovation is in the Entrepreneurial education provided. It points out that this is very different from traditional Business-school curricula. The author, Steve Blank, calls for the creation of Entrepreneurial Schools, or E-Schools, in contrast to Business Schools (or B-Schools). He also would like to see them connect with universities.

I highly recommend Steve's presentation for anyone interested in Startups:

Why accountants don’t run startups sllc from steve blank

I Remain,

TheHackerCIO

Why Hackers Hate WindoZe

2014-05-09T10:47:00.001-07:00

The story of the font.

It's a good example of why Hackers Hate WindoZe.

Sometimes TheHackerCIO does something on a front-end Web site. In this case, I wanted to get an unusual font into the mix on a web page. Stackoverflow held the immediate answer, but when I tried it out, there was no change on the browser page.

After an hours frustration, further googling, and tweaking, I took a break. I washed my face. Then came the necessary reflection.

What are you doing? You're trying to combine multiple learning streams. On the one hand, you're learning the new touch gestures of Windows 8 and where everything has been moved around. On the other hand, you're attempting to actually DO something with WindoZe. So then it clicked. One of the posters HAD said, "any decent browser ..."

And that was the problem. I was using what came installed on the box. I wasn't using a decent product.

So I immediately returned to the laptop, downloaded Firefox, and the font showed. Just for the heck of it, I downloaded all the others -- Chrome, Opera, Safari. All fine. I'd just wasted an hour with WindoZe.

But it's important to have continual reminders. Luckily, I didn't spend that much time on it. I can amortize the time against learning the Windows 8 Touch gestures and re-org.

But you do have to stand in awe, how nothing out-of-the ordinary ever works in a WindoZe environment

After all, why should Microsoft support what every other browser on the face of the planet does?

I Remain,

TheHackerCIO

A Good API is Hard to Find

2014-05-07T12:39:00.001-07:00

API design was the GeekyBookClub topic last night atDev Talk LA.

RESTful Web APIs is the current book, and we had a near overflow turnout for the discussion of chapters 2 and 3.

The book is turning out to be good. But it's the give-and-take of the group that really makes the club work!

Some members have worked ahead, which gives them a bit of an unfair advantage, but TheHackerCIO won't hold that against them. :-)

I particularly liked the fact that the author jumped right in with an actual API to take a look at. A Simple API (chapter 2), in fact, is a micro-blogging API that he uses to illustrate his points. He suggested using wget as a command-line tool to play with it.

I found that I don't have wget available on my MacbookProRetina.

As I mentioned to the group. When someone asks you how long something is going to take, always ask them, "Is this an estimate, or a commitment?" Because management needs to be reminded of this. A lot! Anyway, I curl-ed wget, but I couldn't get it to build because my Xcode was a version or two out, and that download/install seemed to be taking plenty of time. What should have been a 10 minute diversion threw me off for a half hour.

I switched over to simply using Advanced Rest Client, a Chrome extension I highly recommend! You can issue whatever RESTfull calls you wish, with any verb you please, graphically from within your browser, and you can even keep them organized in a file structure for reuse. A very handy tool.

There were too many take-aways from the discussion, but some of the biggest for me were:

1. Being Liberated by Constraints. As the author notes, constraining your REST design, for instance, by using his "personal standard," which requires the JSON to follow some structure, can indeed keep your developers from going wild.

2. I never knew about LINK and UNLINK, but they seem worthwhile. We talked for a while about how POST should be probably be used to create the resource, perhaps with an embedded link to whatever other resource is this resource-target. But then LINK can be used to create a further relationship, going the other direction, from target back to the dependent. (I may be missing something here, because the author tell's me he's going to fill me in on Chapter 11. )

3. PATCH -- looks like a performance enhancement. I'd say to avoid it until absolutely necessary, because it's not idempotent. You're only going to patch a portion of a representation, rather than replacing the whole thing.

4. OPTIONS -- we need to ALL be using this, and straight off the bat, to get the full "billboard" of what we can and should be able to do with our API. No one does. But that doesn't mean we shouldn't start!

5. Overloaded POST -- The author points out how on the web APIs we use POST is overloaded with anything and everything. As he put's it:

The HTTP specification says that POST can be used for:

Providing a block of data, such as the result of submitting a form, to a data-handling process.

That 'data-handling process' can be anything. It's legal to send any data whatsoever as part of a POST request, for any purpose at all. The definition is so vague that a POST request really has no protocol semantics at all, POST doesn't really mean 'create a new resource'; it means, 'whatever.' [p. 41]

And "Whatever", is never a good thing to mean.

So don't mean that.

And restrict your POST to creation of new resources with newly-created identifiers.

I Remain,

TheHackerCIO

Let's Get Physical!!!!

2014-05-06T09:13:00.000-07:00

But as one member noted. Hardware is how we started.

Several interesting themes emerged from the roundtable. The crucial need to find new strategies for keeping up with technology. The Radar isn't enough. It need augmentation. The lab we have is a wonderful augmentation. We need to figure out ways to capitalize on it. Rick pointed out that with the advances in virtualization technology, we can now use a lab in ways that a decade ago simply weren't possible. We can practically learn/design/plan/test/build a virtual datacenter with totally agnostic/fungible kit: cisco, dell, IBM, Oracle, Juniper, ... whatever. We can build it out with one set of physical & swap it later. And a major theme I raised was the crucial nature of fighting with the bugs.

The problems need to be highlighted, rather than worked-through. If anything, it's the problem areas where the learning/growth is going to take place. We need to figure out strategies in the lab to track the issues and problems, and get other to face them as well! That's counter to the way it normally happens isn't it?

But it's precisely the contesting with actual concrete problems that brings the abstract designs back to the reality-point. That's what "Closes the loop."

And that, by the way, was the other major theme of my presentation. Every time I've heard grand abstractions presented, and I've been able to force through an actual physical, concrete implementation example, the disconnect between the theory/abstraction and the concrete/implementation has been immense. Enormous. Totally surprising. So much so, that I now almost completely discount abstractions presented in the lack of any supporting test example or demonstration.

One of our further goals for The group, in conjunction with our partner Meetup, L.A. Cloud Engineering Group, will be our attempt to produce a crowd-sourced eval platform -- probably with a Geeky/Social approach -- where in my view, capturing such "proof points," "test cases", "demonstrations," or even "benchmarks" in a repeatable, verifiable way will be a central feature. I might even create a widget/button called "Prove it, dammit!"

That might go a long way toward getting people to close the loop.

I Remain,

TheHackerCIO
At Technology Radar Group, last night, TheHackerCIO presented on getting physical.

Physical.

Because it's been too long.

Seeing a lot of hardware hackers at the AT&T Wearables Hackathon, back at years end, was partially a reminder.

But as one member noted. Hardware is how we started.

Several interesting themes emerged from the roundtable. The crucial need to find new strategies for keeping up with technology. The Radar isn't enough. It need augmentation. The lab we have is a wonderful augmentation. We need to figure out ways to capitalize on it. Rick pointed out that with the advances in virtualization technology, we can now use a lab in ways that a decade ago simply weren't possible. We can practically learn/design/plan/test/build a virtual datacenter with totally agnostic/fungible kit: cisco, dell, IBM, Oracle, Juniper, ... whatever. We can build it out with one set of physical & swap it later. And a major theme I raised was the crucial nature of fighting with the bugs.

The problems need to be highlighted, rather than worked-through. If anything, it's the problem areas where the learning/growth is going to take place. We need to figure out strategies in the lab to track the issues and problems, and get other to face them as well! That's counter to the way it normally happens isn't it?

But it's precisely the contesting with actual concrete problems that brings the abstract designs back to the reality-point. That's what "Closes the loop."

And that, by the way, was the other major theme of my presentation. Every time I've heard grand abstractions presented, and I've been able to force through an actual physical, concrete implementation example, the disconnect between the theory/abstraction and the concrete/implementation has been immense. Enormous. Totally surprising. So much so, that I now almost completely discount abstractions presented in the lack of any supporting test example or demonstration.

One of our further goals for The group, in conjunction with our partner Meetup, L.A. Cloud Engineering Group, will be our attempt to produce a crowd-sourced eval platform -- probably with a Geeky/Social approach -- where in my view, capturing such "proof points," "test cases", "demonstrations," or even "benchmarks" in a repeatable, verifiable way will be a central feature. I might even create a widget/button called "Prove it, dammit!"

That might go a long way toward getting people to close the loop.

I Remain,

TheHackerCIO

At Technology Radar Group, last night, TheHackerCIO presented on getting physical.

Physical.

Because it's been too long.

Seeing a lot of hardware hackers at the AT&T Wearables Hackathon, back at years end, was partially a reminder.

But as one member noted. Hardware is how we started.

Several interesting themes emerged from the roundtable. The crucial need to find new strategies for keeping up with technology. The Radar isn't enough. It need augmentation. The lab we have is a wonderful augmentation. We need to figure out ways to capitalize on it. Rick pointed out that with the advances in virtualization technology, we can now use a lab in ways that a decade ago simply weren't possible. We can practically learn/design/plan/test/build a virtual datacenter with totally agnostic/fungible kit: cisco, dell, IBM, Oracle, Juniper, ... whatever. We can build it out with one set of physical & swap it later. And a major theme I raised was the crucial nature of fighting with the bugs.

The problems need to be highlighted, rather than worked-through. If anything, it's the problem areas where the learning/growth is going to take place. We need to figure out strategies in the lab to track the issues and problems, and get other to face them as well! That's counter to the way it normally happens isn't it?

But it's precisely the contesting with actual concrete problems that brings the abstract designs back to the reality-point. That's what "Closes the loop."

And that, by the way, was the other major theme of my presentation. Every time I've heard grand abstractions presented, and I've been able to force through an actual physical, concrete implementation example, the disconnect between the theory/abstraction and the concrete/implementation has been immense. Enormous. Totally surprising. So much so, that I now almost completely discount abstractions presented in the lack of any supporting test example or demonstration.

One of our further goals for The group, in conjunction with our partner Meetup, L.A. Cloud Engineering Group, will be our attempt to produce a crowd-sourced eval platform -- probably with a Geeky/Social approach -- where in my view, capturing such "proof points," "test cases", "demonstrations," or even "benchmarks" in a repeatable, verifiable way will be a central feature. I might even create a widget/button called "Prove it, dammit!"

That might go a long way toward getting people to close the loop.

I Remain,

TheHackerCIO