Archis's Blog

October 31, 2014

Immutability simplified

Immutability, as used in software engineering, brings much fear and paranoia. I figured out today morning why that is. It evokes visions of fixture, restrictions, dogma, lack of change, straightjackets, chains, prisons! Read below to find out that immutability is about far more reckless and carefree change than you can possibly imagine.

First remember that immutability is simply a concept, a principle, etc. Imagine a “Thread of software”. You may call things threads, processes, strings, ropes, etc. These are all concepts. From the silicon’s view, it is getting a stream of instructions that it executes. It doesn’t know that you have multiplexed the stream with conceptual ideas. Immutability is simply an idea, that if you guarantee me certain things won’t change without my knowledge, then I can save significant time and effort being wary of those changes. At what level you provide that guarantee is entirely upto you. I think the crucial component people leave out, when they describe immutability, is the hidden clause, “without my knowledge”.

If you think in terms of procedures, this can be very truly frightening word. Afterall, everything about software is change. We change states. We grew up learning about state machines. There are two parallel reactions I have seen on blogs that promote immutability.

The first one assumes that the author is trying to be a showoff. “What the author wants, is for me to get it right the first time. The author can do it right in one shot, but I can’t. We’re not all math geniuses professor. We’re just engineers who write code, and it works. Go live in your ivory tower you stuck up snob.”

This is simply based on a misunderstanding of what immutability means. In the second paragraph I spoke about change without others’ knowledge. We’ll get around to that again.

The second one assumes that immutability is this one single thing. Let’s explore that further. If you’re interested in general language discussions, it would help to read this post on strong and weak type systems by Eric Lippert. If you already know, I want to draw an analogy between strongly typed references vs strongly typed values – even in a dynamic language, you can have values that are strongly typed, even if the references to those values necessarily aren’t.

In the same way, immutability has many many forms and shapes.

For example, in some languages,

x = 2

y = x

y = 3

Is a logical fallacy. The compiler would fail. As a mathematician, you clearly know that the code above is “not true”. Let us call this type of immutability, a “immutability of reference”. These are not assignment operators, if that is how you think of them. These are facts being given to the compiler. You are informing the compiler that y is 2.

But I’m sure we’ll all agree that the following (interpreted as C code) is very very bad:

int const TWO = 2;

int* x = &TWO;

int* y = x;

passYToThisFunctionToBeDereferenced(y);

*x = 5;

What’s wrong here? By pointing x and y to the same address, and after having passed y to some function, I change the contents of the value itself. Remember, if I simply repointed x to some other place, all would be well. But if *y was being used as a loop invariant inside a function, and suddenly *y’s memory contents changed, wouldn’t that be an incredibly difficult bug to track down?

In fact, this is why all mainstream languages like C, C++, and Java pass by value. Because the target function receives a value, not the reference to a value.

And that, is immutability. :-) That’s literally all it is!

So then why is it such a big deal? Because copying objects is incredibly hard, expensive, and many times, downright impossible. Imagine you had an object that held a reference to a file handle, or a network socket. You can’t just copy it and pass the value. You need to pass the actual object!

Immutability doesn’t mean that you make data unmodifiable. In fact, far from it. If you are used to coding in the C example I gave above, you are used to coding in an environment rife with fear and paranoia. You have wisened words from old developers that warn you of the dangers of changing values without knowing what you are doing. Who knows what will happen if you change the memory that x points to. Your movements are restricted. You are chained. Your freedom curtailed. Innovation destroyed. Ideas discouraged. A truly frightening world it is. That’s no way for a programmer to live! That’s abysmal! We can do better! We MUST do better!

On the other hand, immutable data structures deliver just the opposite.

FooUser Y = new FooUser(); //Y needs a Foo to operate correctly

Foo x = Foo();  //x can change. The object that x is referencing can’t change.

Y.functionThatNeedsX(x); //This is safe. Can’t hurt him no matter what we do

x = new Foo(); //innovate

x = new FooWrapper(x); //use that new idea

x = x.addStuff(2); //Wheeee. Freedom!

So how the hell does Y know that it needs to use a new Foo? The question writes it’s own answer:

Y.heyYouNeedToUseANewFoo(x);

That’s it! You TELL Y something has changed. You can tell Y as many times as you want, as many things as you want!

But aha! Y itself is an object isn’t it? There are people holding a reference to Y, and you can’t just outright change their assumptions, otherwise soon, this is your doc all over again:

class FooUser {

/*Ancient wisdom. Don’t call this if you’re past the post-back phase, except if you’re running on Machine Y, and under these conditions. Or else!       */

void heyYouNeedToUseANewFoo(Foo x) {

this.x = x;

}

}

Uhggg!!!! Who wants to live in this person’s world? It is positively horrid. It is restrictive. It is uninnovative. Can you imagine being told not to do things when you want, how you want, where you want? How the hell do you change the world with that kind of platform? Hell no! We do this:

class FooUser {

/*Hey there, what’s up. Call me for drinks later.       */

FooUser heyYouNeedToUseANewFoo(Foo x) {

FooUser fu = this.copy();

fu.setFoo(x); //private method;

return fu;

}

}

Remember immutability is a concept. It is upto you how, where and when you apply it. But everywhere that you CAN apply it, becomes a happy place of innovation, where anyone can come in and do their thing. Ideas can be expressed faster. Fear is gone. Threads can play. Cores can play. Processes can play. Huge clusters can play.

I hope this clarifies that immutability ironically encourages massive change, while itself denoting lack of change.

October 10, 2014

When everything’s important, someone’s lying.

Filed under: Uncategorized — archisgore @ 5:56 am

A tough lesson in the software world, and a sobering reminder. Also a statistical truth (not mathematical, though.)

If you ever read about or studied probability theory, process control theory, quality assurance (modelling, predictability, reasonability, etc.), clinical trials, or just about any kind of applied science, you know that this is both theoretical truth, and empirically proven. You can always make improvements that tend towards correctness. But the only way to reach absolute perfection, is to never conduct the experiment at all.

There is no way to ever reduce false positives to zero, nor reduce false negatives to zero. This is why we have acceptance criteria. Cars today are safer than they were a decade ago. But the only way you ensure you are always absolutely safe in a car, is to never sit in one. It sounds counter-intuitive and difficult to grasp.

I recently read an article about the expensive experiment that OOP was, and while you may disagree with the article, you will notice the True Scotsman fallacy.

Sidebar: Why doing what you can do, instead of what you need to do, makes for great religion, but rarely useful.

I make fun of the mystics and snakecharmers, but one thing a yoga guru once said to me ten years ago, and what seemed like a dumb thing at the time, holds true for so many adults. He gave the example of the person who has lost their keys outdoors, but are searching for the keys indoors because that’s where the light is. They are virtuous because they are at least doing something, unlike me, who is making the smartass observation that they will never find the key indoors because that’s not where they lost it.

Why do I equate it with religion? Because religion allows you to do anything, and always be right. Need to feed the hungry? Sure. Need to NOT feed the hungry? Sure. Support gays? Sure. Not support gays? Sure. Invade Jerusalem? Sure. Defend against invaders? Sure. Forgive people? Sure. Not forgive people? Sure.

This has always been my observation with “frameworks”, “patterns”, “best practices” and especially, “testing”. You can write a few hundred tests that do nothing, or you can write one test that guarantees correctness. But if you’re having system problems, and you’re doubling-down on writing more tests, you’re looking indoors because that’s what you know how to do, instead of searching for the keys outdoors where you dropped them. It is exceptional religion. Also exceptionally useless. None of the above can fix a problem, and if you’re just about thinking of saying, “Well, what would you have me do? I have to do something!”, then you and I both know you’re lying.

Interesting note: Doing something is not necessarily bad. It is psychologically very helpful in fact. CPR rarely works as often as they show in the movies. Neither do defibrillators. The first thing they teach you in a first-aid class, is that CPR is 95% for the psychological protection of the rescuer, and 5% for the benefit of the victim. It helps you avoid PTSD because you had the illusion of agency – you acted, you did something!

 

This is why there are very few people in our industry who can really critically cut down to things that ARE important and those that ARE NOT. Remember that because something is NOT important doesn’t mean you go around sending a wave of crusaders to destroy it – another wholly inaccurate interpretation most people make.

Ask anyone about ACID consistency, or scalability, or correctness. Is testing important? YES! Is scaling important? YES! Is reliability important? YES! Are ALL requirements important? YES! Is there something you can live without? NO! Alright – someone’s lying. One of the above is most certainly NOT true.

When I’m reading documentation, or looking for tools to use, the biggest red flag I look out for, is when a system has made no compromises. Knowing that such a thing is theoretically impossible, I’m probably dealing with someone in denial – which is worse, because that means, like a religious zealot, I have no ability to hold a critical discussion with them. This isn’t so difficult to find. Can an iPhone be improved? Unless you live under a rock, the builder of the iPhone, Apple, releases improvements every year. Ask any fan of Apple the same question – you’ll get the same answer, “No!”. Guess which of them is lying? Can Android be improved? Can Java be improved? Can Linux be improved? On that last note, you’ll find Linus himself laying down a whole host of things he wished he’d had. He’s well aware of the compromises he’s made in the kernel, and he continues to make – and he publishes them too. 10 points if you figured out which of them gives me the best confidence that I’m dealing with the right person.

People have been wrong in the past, and people will continue to be wrong, long after we are gone. I have changed my mind about so many things, so often, its not even funny. The only reasonable change we have of building a good system, is by recognizing the compromises we make. As I wrote in my last entry, I’m available to give you hugs if “compromising” somehow diminishes your self-identity.

If you’re going to tell me that you want everything, perfect, all the time, I’m not putting my faith in you. Either you’re lying to me, which is bad, or you’re in denial, which is worse.

September 18, 2014

Software Design: Learning to identify Dislike vs Exception.

Filed under: Uncategorized — archisgore @ 12:20 pm

This is a subtle point I learned over the past year. You know how I’ve always hated Frameworks. The repeated irony in my blogs is that I’m a crazy academic process-Nazi when speaking and yet seem to disregard every bit of process, apparently when it suits me. I assure you there’s a method to the madness (see Sidebar 1).

Sidebar 1: I evaluate everything by statistical significance. Here’s the deal – if your child was taken hostage and a terrorist demanded money. You know the terrorist has no predictable consistency when it comes to releasing hostages after the ransom has been paid (i.e. there is no process that you know of.) You have two choices you either pay the ransom or you don’t. Let me add a twist (See Sidebar 2) – the terrorist also has no predictable consistency of releasing hostages when the ransom isn’t paid either. Let that sink in for a moment. The cover-your-ass thing to do is to always pay the ransom – because then you did everything you could. The cost-effective thing to do is, never pay the ransom, because there is no correlation of your action to the outcome, but in the first scenario you always lose money and in the second one, you never do. This one is genuinely difficult to get around mentally. You’ll accuse me of being inhuman. You’ll give me a lot of philosophy. The math doesn’t change.

Sidebar: One of the best critical-thinking tools you can use, is to frame the converse/inverse/contrapositive of every statement you hear. It is a great tool to identify if what you’re getting is “information” or not. Sometimes people imply causality without explicitly saying so. In normal words, they passive-aggressively accuse you. Consider this: “You were late today. I didn’t have anything to eat.” It is a very counter-productive way to have a conversation. I don’t know if I’m being criticized for being late – which I totally deserve. I don’t know if you want sympathy for not having eaten – which you totally deserve. But the question is, if you had somehow had something to eat, would my being late, be acceptable? THAT’s the question which determines whether or not you are having a constructive conversation or not. Use it the next time makes a comment without actually making a comment.

I treat all processes the same. A process that provides even the slightest bit of causality, I will uphold with an iron fist. A process that is designed to make us “feel good” does nothing for me. Either it is contributing to my success or it isn’t. If it isn’t, I have very little tolerance for the ceremony of “having done everything I could.” – because it costs a lot of money always, and doesn’t predict anything. Moreover, it has the risk of setting up a dangerous trap where people invent new ways of non-causal crap to do, do demonstrate they did everything they could. It’s like a religion where people hurt themselves or become poor for virtue – not that it objectively made them “better people”, but so long as they self-inflicted unnecessary pain, I’m somehow supposed to believe they overcame tragedy.

That leads us to the main point of software design. A widely misunderstood interpretation of the word “Exception” is that of dislike. I’m going to emphasize heavily that we understand the two are not one and the same.

I dislike many things about how software works. I wish nobody used recursive locks. I wish nobody created global variables. I wish nobody passed large objects by value. These are things I dislike. But I do all three of them all the time. Meaning, they are not done under exceptional circumstances. By definition, a situation has to be less than, if not equal to, what I do most of the time, for it to be called an “exception”.

Let’s pick on my favorite “framework” I love to beat to death – WCF (or SOAP, or CORBA). Every single SOAP implementation I have ever seen – literally EVERY SINGLE ONE has had an “exception” for passing HTTP headers. You should see where I’m going with this – it is not an exception. It is something the designers of SOAP disliked heavily. However, when HTTP is the most common protocol used for transporting SOAP messages, then manipulating HTTP headers is not an exceptional and extravagant scenario.

This is important because that is what ruined SOAP for me every time. Walk up to any old-school SOAP person, and you still have to put up the same fight all over again to “hack” your SOAP client to allow passing extra headers. You both know it’s necessary. But you both have to pretend like you’re somehow the exception to the rule, and that other SOAP implementations don’t do it.

If the SOAP authors had admitted and written a note saying just how much they absolutely detest application developers manipulating low-level protocol details, we’d have vehemently agreed with them, given them a hug, bought them a beer, and bitched about it. Instead, they turned their dislike into the “rule”, thus making everyone call the most common scenario the exception.

It is important in designing a system to understand why and how it is going to be used. If you don’t want people writing HTTP headers, that isn’t done by making it difficult to write code for – we’re used to writing difficult code. We get promoted by writing complex hard-to-understand code! It is done by providing a service design that won’t require it. Adding hoops and a thousand unit tests and process requirements doesn’t make a good software architecture. Removing the incentive to do the undesirable thing works wonders, on the other hand.

The next time you’re building something – ask yourself this question – is your system going to be broken under truly exceptional, truly uncommon, truly extravagant circumstances? If not, then educate your consumers on how to avoid the pitfalls. Don’t make their life annoying by adding barriers. I feel your pain when people do stuff you don’t want them to. I’m available for hugs if you need any. Education is the only way to fight fear and paranoia.

June 29, 2014

Why Programming Languages matter (and how you may choose wisely.)

A colleague asked me a couple of months ago, what determines my choice of language – or even paradigm and that had already motivated me to write a draft on this. This past week, I spent in Silicon Valley at a conference. This would be the first time that I actually interacted with the “hack3rs” and startup-junkies and techies and what not. I learnt a lot of buzz-words I had never heard of before, but I did walk away with one major take-away – even startups that are trying to be lean and simple, tend to complicate things beyond belief!

You can separate out the ones who “get it” vs those who don’t. The talks by Google, Facebook and Akamai engineers were captivating. They operate on a higher-level of problem space. This is not because of money, size or scale – it is simply because they choose to brutally simplify that which does not matter – so that they can focus on what does matter.

So in the backdrop of me pushing my own team to consider bringing in higher-level languages or even using full object-oriented as it was meant to be used, I found that a lot of new-age startups didn’t “get it” either. They use Javascript and Python and Ruby, but they have no clue why.

Now admittedly there is value in writing a more compact loop, or avoid boiler-plate code. But if that is the only reason you are considering a programming language, you’re doing it entirely wrong. I’ll take an FFT written in BASIC any day of the week and twice on a weekend, as opposed to a correlation-DFT on a multi-core parallel futures-dependent async map-reduce framework on top of hyper-optimized vectorized C++.

So what should influence the choice of language? One question and one question alone: Am I saying what I want to say?

After putting aside reasonable performance requirements, all the requisite functionality, etc., the language needs to allow you to express your intent, not only to the compiler, but to a future reader. It is my belief that 99% of the reason behind all failed attempts at making software maintenance possible, lies the inability of the original programmers to express their intent. What is documentation if not expression of intent? What is a UML diagram if not expression of intent? What is Object Oriented Programming, if not expressing intent of WHAT operations are possible on WHAT data? It isn’t as if the old C-style ModifyWindowEx(HWND wnd) didn’t work, but Window.modify() tells you and the compiler, what is possible on that window, and what is not. It is expression of intent.

Fortran was huge back in the day, because it expressed your formula. Instead of reading:

MOV AX, $5D
ADD AX, $6F
MOV $7F, AX

You could say:

c = a + b

So you know that the entity “a” was to be added to entity “b”, and the result stored in “c”. You don’t even need to know computers to tell me what that means.

The common misinterpretation of this concept is that “Functional languages allow you to say what you want, and imperative languages allow you to say how you want.”

That is a terrible way of looking at it. Because sometimes “how” you want something is what you’re trying to express.

Like all my blog posts, I’m going to give you that fundamental question to ask yourself when choosing your language:

“Did I tell people what my intent here was?”

If you can’t answer that question directly by the language, you’re using a non-optimal fit. When you have to write documentation and code comments, that means your language failed at expressing intent. Take the example of this prototype:

char* reverseString(const char *foo);

Without extensive documentation on treatment of nulls, empty strings, and exception-handling capabilities, there is no way to understand what the author of the function intended this to be used for. This is BAD! Sure there may be tons of input validation inside the function, but now you have to write a dozen unit tests for a dozen scenarios to ensure that assumption isn’t broken.

What do I mean by intent-expressivity? Suppose C++ allowed hypothetical annotations that could be made part of the prototype metadata?

char* @Nullable reverseString(@NonNullable const char *foo);

If those annotations were stored at the prototype metadata, you got two benefits:

1. You never need tests to ensure foo is non-null. Your compiler did whatever it had to, to give you a non-null char pointer.

2. You expressed to your caller, in no uncertain terms, that you will not tolerate nulls. You expressed it in a way that the compiler understood, and a smart static analysis tool would catch a class of bugs not possible in plain-old-C.

While this appears to be cosmetic syntactic sugar, it is far far more than that – it is semantic sugar. Now any analyser, man or machine, knows that having foo being null, will not be entertained by my function. Rather, you’re locking down the domain and range of the function. It looks very very silly that I would care about such a thing.

 Functional Programming isn’t the answer to everything:

Another common misconception about me is that I want pure-functional languages. Oh boy do I love them dearly, and for good reason. See that expression above?

c = a + b

what if I wanted to add the result of two expressions?

c = (expr1) + (expr2)

What if expr1 has side-effects that affect expr2? This isn’t an unseen situation:

c = (a++) + (a + b);

The problem here is not the one you think it is. I know what you’re thinking: “Who knows how this language interprets that statement? What happens if the evaluation order got changed?”

And you’re WRONG! That kind of thinking is what allows such features to live. There is an easy answer to what you thought was the problem. The answer may be reading the compiler spec.

The real problem with the expression above, is I have no way of knowing whether that sequencing was incidental or intentional. I can deterministically answer what will happen above. What I cannot answer is, was that intended? If I had to optimize the method above for running in a loop. If I had to make it so that it could be invoked by multiple threads, possibly running on different cores. If someone asked me, “If I set value of variable z to 10 instead of 20, will it affect your value of c?”

Then it is theoretically impossible[1] to answer that question. Sure we could heuristically make some assertion, after adding a thousand caveats (or just one caveat), but as a reasoned outcome, we cannot say, that z somehow didn’t affect a or b. Furthermore, multiple evaluations of the expression above cause “c” to change.

Why is that important?

Because the ability to reason is the ability to maintain. You want to know why CSS sucks? It isn’t horrible, like most people think, because people write it wrong, or because designers mix font rules with layout rules. CSS sucks because it literally removes any and all ability to reason about the intent behind any rule, without massive comments.

Remember that a rule-based declarative language isn’t exactly new or revolutionary. Prolog gave us the CSS-style declarations 50 years ago. Erlang gives them to us today in a widely used industrial language.

If I showed you the code below:

div .title #subtitle {color: blue}

I bet you, you would have absolutely no freakin clue what effect this has on a particular page, without actually loading the page. It makes no mention of how it is supposed to be interpreted in relation to other rules. It makes no mention of how it relates to conflicting matches.

So for all you Ruby/Python/Node.js users out there, I have one piece of advice – if you truly want to out-do the “establishment” and gain an edge – do what Google and Facebook does. They use experimental technology, but they don’t do it to reduce boilerplate code in for-loops. They use it to express their intent for their loops. Rapid development is a good enough reason to pick an easier language. Accurate expression of intent is the best reason to pick any language.

When Imperative matters:

To finish up, I wanted to explain why imperative programming matters. Look at a device driver for instance:

setlpt1(00000000b);

setlpt1(00010000b);

setlpt1(00000000b);

That’s some primitive protocol I made up for the parallel port. Those statements are organized chronologically. Even 200 years from now, that is EXACTLY what they mean and what they must do. To use imperative programming where necessary, provides a strong signal to the reader that this code is NOT to be messed with. There is no opportunity to reorder those operations. There is no opportunity to apply them to abstract “ports” – they only work for the “parallel port” or “printer port of old”.

Writing the above in a functional language, and then adding synchronization primitives to ensure they run sequentially, is folly.

Conclusion:

If there’s one take-away I can summarize from this post, the next time you write ANY code/spec/program, ask yourself – did you express your intent properly? Did your choice of tool/language allow you to express it semantically without ambiguity for interpretation? Was it done in such a way that a future maintainer, would know what your constraints are? Without reading a single code-comment or documentation? If you answered yes to most of the above – you’re probably using the right language, and using the right language right.

May 24, 2014

Why can’t we evolve from WordStar?

Filed under: Uncategorized — archisgore @ 10:10 pm

Ever tried to delete code in your project? Ever tried to nuke entire directories because you thought they were irrelevant? Even found a build break and wanted to revert another person’s code? Ever find yourself commenting out code because you weren’t sure it’s needed? Ever notice how in all these situations, developers forget that we’re no longer using line editors and tapes to store all this data?

Why is it that the same person who can comfortably handle every new programming paradigm you can come up with, suddenly becomes a punch-card programmer when it comes to code histories? We all do it – admit it. How many times have you actually gone out and nuked code for the good of mankind?

This is one of those pet peeves that REALLY REALLY amuses me and annoys me.

“Whoa whoa… are you sure you want to delete that? What if we need it?”

“Uhh….. its in the revision control system. You DO realize we can get it back don’t you?”

The counter problem is equally primitive. If I’m on vacation and I’ve done something stupid (we all do it – admit it), I totally expect my code to be reverted, because… when I get back, I can find it again!

See back in the days of CVS, revision control was simply a backup. It allowed you to go back in time. It didn’t necessarily look at your repository as a repository of changes that can be used or not used. (also, if you’re not using Git, you totally suck!) So back in that day and age, “revert” was akin to a “nana nana naaa naaa” by your coworkers, or a “Ha ha” by Nelson. A revert meant everyone’s work got undone and they went back to the drawing board.

In today’s day and age, it is somewhat perplexing to see all these cutting-edge-software-system-builders suddenly behaving like the hoarder grandma who who has 15000 files in her documents folder because what if she needed it in the future?

May 23, 2014

One more dive/rescue principle applied to general software design and decision-making

Filed under: Uncategorized — archisgore @ 9:24 am

Another one where, the diving/water world makes an excellent analogy to think about your programming problem. Most of these things you already know, but putting a potential life-threatening situation into the mix makes for a compelling argument rather than hypothetical analogies.

Many of you have heard the story of that one time I was sitting in a room with five principal engineers debating whether or not to use a 32-bit integer for something, and then everyone ended up taking it offline (programmer-speak for: we reached no conclusion after six hours and we got really really tired.)

Now divers face many decisions. For better or for worse, I am a fan of George Irvine III – an obnoxious person who sounds really like Linus Torvalds. If you want to disagree with him it’s your choice. But if you want to submit code to the Linux kernel, you have to do what he says.

When you watch any videos or read any articles by George, you tend to find some exceptional quotes which you can apply to any decision-making problem and help improve your chances of success.

Plan for the working portion of the task

Many people have tried to dissuade me from the gear I use. None of their arguments make sense to me ever. The first argument I ever heard was, “When you’re underwater, you’re in a hostile environment. That is when you need to be comfortable and efficient. All of your gear must be designed to perform for THAT situation. All else is secondary.” So any arguments that tell me how something will make my life simpler when I’m gearing up in the back of my truck, or doing something on land – they fall on deaf ears.

This is the most important lesson I have recently begun applying to my programming designs.When the code is going to fail (and fail it will), THAT is what it must be written for. It is not written for the initial code review. It is not written to get your manager’s pat on the back. It is written for that situation when, during a failure, someone who is only vaguely familiar with it, needs to be able to figure out what you did, why you did it, and how it works, so that they can figure out why it is failing.

It changes your point of view on writing code as well as reviewing others code dramatically – at least it did mine. When I’m about to do that neat little trick, or use that awesome closure-chain to show off my abilities, the question I ask is, how will this perform in the working portion of its life? Can it be understood? Can it be fixed? Can it be replaced? Can it be shut off without side-effects?

If that means an uncomfortable code review, or a slightly annoyed team member, that is secondary. When it isn’t checked in, it is equivalent to being on land. You can save it out of many emergencies and dangers. It is once it is underwater that it needs to perform.

Remove all incentives to make mistakes during a stressful situation

I’m sure we’ve all been in those arguments where we go, “Oh I know someone can screw up my sort. But nobody ever will. If they do, we will make them fix it.”

Interpret this from a diver’s point of view: Someone has an easy way to kill you. But who would kill you intentionally and knowingly? If they try to, I will ask them to simply stop.

Do you really believe a panicking person fighting for his life, can be asked to stop and NOT try to kill me? His brain is probably working on autopilot at that moment, and the ONLY way I can survive, is if NOT killing me is the intuitive choice for him. We use a system called “primary donate”. The reasoning being, a distressed diver is coming for that regulator in YOUR MOUTH. Rather than hypothetically reasoning with him, we simply plan on it. We know what the default reaction will be, and we simply let it be dragged out of our mouths. If the diver is reasonable and calm, no harm done. We still give him the hose from our mouth. But even he isn’t calm, still no harm done. We planned for it all along.

This principle is a very subtle and yet oftly overlooked way to look at it.

I’ve become the annoying guy lately who constantly asks the one question, “When a billion dollar business case comes to us, and something needs to be done STAT, are we going to be able to fight back. Are we going to be able to push back then?”

See, it’s always easy to plan for beautiful architectures and great designs and powerful patterns when designing a framework – that’s your full-time job. Too often people plan for everything except when someone is trying to take the easy way out, and is under tremendous pressure to do so.

So anytime I design an API or a framework or think about a problem, I try to optimize for the case where, under stress, I need to put up road signs and markers and hints such that what I want them to do, will be the cheapest and simplest thing for them to do. Thus for them to do something else needs to cost them more in terms of time or effort.

I actually lose patience and tolerance for comments like, “Nobody will ever use this API the way you described.” Instead plan for, “Inevitably, someone is going to abuse that API of yours, whether you like it or not. That’s totally fine and expected. All we need to do is, make sure that the right way is EVEN more intuitive and cheaper and simpler than that.”

The reason relating it to a life-threatening situation makes it better to conserve is, we try not to think of people in judgemental terms. Remember, when a person has 10 seconds of consciousness left, has no breath in him, and is in a panicking state, they aren’t taking your regulator to be sadistic assholes for the sake of it. They are doing what biology is commanding them to do.

It is a lesson worth remembering in the programming world too. If you provide a facility to hijack some function, it WILL be hijacked. If you provide the facility to put your method in an infinite loop, it WILL be put in it. If your stringly-typed parameter can be sent something NOT part of an enumeration, it WILL be sent something not part of the enumeration.

This we already know. The lesson is, that people aren’t doing it because they’re assholes, and thus the machoistic grandstandng attitude doesn’t apply, where we think, “Yeah, bring it jackass. Try and break my beautiful design. I dare you.”

In my experience of 8 years, NO code has ever been broken due to this, that I know of. People are well-meaning, kind, amazing, wonderful human beings. However, when they are under stress, the human body’s reaction is to first remove itself from stress, and THEN worry about other things. Now you can make it easier on them by ensuring that the “expected action” is also the “cheapest, most intuitive, easily identifiable action to remove myself from stress.”, or you can make it harder on them by making it “well to do the right thing, you have to jump three hoops and a ring of fire. Also, if you do the wrong thing, you’re labelled an asshole for life.”

April 17, 2014

“The password you entered does not match”

Filed under: Uncategorized — archisgore @ 12:00 am

A story of space…

When I was 10, it was already 35 years into the space age. Humankind had made it onto the moon. I was fascinated with reading as much as I could get my hands on, about the Apollo and Gemini missions. It would be my first introduction to redundancy. This was the era when computers were hilariously primitive. With no software development discipline, no formal verification methods, no historical learnings to depend upon, how would these machines be kept reliable? The answer was both elegant and ingenious – two separate contractors would build two independent computers in isolation, designed to perform the same calculations in real time. When they disagreed on their computations, that’s when the pilot would be alerted.

While it took me 20 years to understand what they did, they weren’t really providing redundancy in the true sense of the word. They were testing the system LIVE. One of the systems (picked arbitrarily) would be treated as the product, while the other system would be treated as the validation test.

It is a simple and powerful concept. When in doubt, simply rebuild the entire system all over and see if it matches. The chances of making mistakes in both systems is, without a doubt, very high. However, if it could be shown that the chances of making the same mistakes in both systems is very low, then you might be on to something. For very little knowledge of any software discipline at all, you could still build a pretty damn good quality system.

While you continue reading the rest of this post, try and answer the following question: What does a mismatch in calculations tell you? Try and enumerate the implications of that predicate. It’s going to be important later, because that will directly determine what we can do with that information. If we wish to do nothing about it, then having the validation in place, achieves nothing, but costs us a lot.

The story of ECC and Parity bits…

Anyone who’s taken basic CS classes knows about a parity bit. It goes something like this:

You know that game you play where you are standing in a row of people on stage.The game show host whispers a particularly tough-to-remember phrase to a person standing on one end. They have a limited amount of time to repeat it to the next person and so forth. Eventually the person standing at the other end has to repeat the phrase as they know it best.

Let us assume this phrase was “much would would a woodchuck chuck if a woodchuck could chuck wood“.

Now there are a few tricks each participant can use to ensure the person they relayed it to, got it correctly. One way I just made up, would be to add two bits of metadata: “wood: 5, chuck: 4

A modified phrase to pass around, for some extra memory length is:

“much would would a woodchuck chuck if a woodchuck could chuck wood. Wood: 5, Chuck: 4“.

The last participant then, if something was missed, could generally reconstruct the phrase within rules of grammar (implicit in the universe), and far simpler metadata, the numbers 5 and 4. It also gives the precedent a chance to validate that the relay has happened correctly.

This how all electronic communications works. There’s relays upon relays upon relays. Mediums change and encodings change. This is in a pure universe with no malicious attacker. We’re not talking security here. We’re talking reliability. Just like in the example above, when bits are transmitted, two parties could make simple agreements with each other.

First, that any numeral can only be a zero or a one (just like English grammar being implicit). Usually this rule is enforced by the medium itself.

Second, that the number of 1st must necessarily be even (or odd).

So if I’m transmitting a number: 10011000

With no knowledge of electronics or binary coding, and having even the most basic ability to write messages, I can ensure that my message, as relayed to my friend has an error on it. There are three 1’s and five 0’s. What if the number I wanted to send was the above. Then I would simply append an extra 1 to the right making four 1’s and five 0’s. The agreement being that my friend always looks at the left-most 8 digits.

This is how parity bits work.  ECC (Error Correcting Codes) use a similar principle but are able to detect which digit was broken. Thanks to our first rule that only two digits are allowed, recovery is trivial – since it can only be 0 or 1, and we know that it is wrong, we make it right by changing it to the opposite.

You’ll notice that in this example, I gave you the answer to: what a mismatch in expectations tells you.

Testing, QA and Validation

The main purpose of this post was to comment on how to write tests, when, for what and why. The two examples above are great references to keep in mind when designing a test.

When writing any test you should be able to answer two questions crisply:

1. What does passing this test tell me?

2. What does failing this test tell me?

If you cannot answer these questions based on a test, you need to rework your test-case.

Why is this so important? Because like NASA, your test’s primary job is to smell something is fishy. You don’t know what is fishy. You’re not sure if it’s cosmic radiation, or a programming bug, or even a bug in the “comparator” (remember that the thingy comparing the output of two simultaneous computers is also human-made – it is susceptible to all the wonder and amazement and limitations that come along with it.)

Furthermore, a quality test should, like the ECC, tell me what is wrong. More than often, think of tests as being published, not written. Your tests are a publication to your peers, broadcasting to them the expectation you have from something. So when that expectation is broken, the test has to tell them what it was.

In FOPL terms, a test should guarantee that
1. P->Q (P implies Q) (If this test passes, then you did nothing wrong.)

However, further more, it should also meet the contrapositive

2. ~Q->~P (Not Q implies Not P) (If you did something wrong, then this test MUST fail.)

 

 “Your passwords do not match”

I finally come to an explanation of the title. When you create an account on any modern webservice, you are asked to enter a new password twice. What is the purpose of that?  What predicates does it allow us to make? When passwords match, and when they do not match?

The answer is very few. As in, all we can say is, the passwords you entered do not match. Is any one password more valid than the other? Is one password more proper than the other? We simply do not know.

However, when we write tests, we derive a false sense of security when qualitatively, all that the test is doing, is the above. Let’s go into a few examples.

1. A sorting test:

In order to catch a possible memorization scenario, I argue that a real sorting test generates previously unseen inputs and sorts them itself, and produces outputs. This ensures that someone hasn’t simply programmed if (condition) then return “solution” kind of functions.

However, it isn’t as trivial as it seems. What if they did? If they implemented a non-stable sort (Quicksort), and your test validates against a stable sort (Mergesort) – who is more “right”?

Remember the two questions posited above. If you implement a quicksort all over again, then you mandate quicksort behavior on the implementation – which means you’re not really writing a test. You’re doing the “two passwords don’t match” thingy. If you DON’T implement a quicksort, you’re impostng rules that are not part of the expectation.

2. CheckIf<SomethingIs>

This is a common annoyance. Let’s say you’re Startup and you’re writing a program to generate terms and conditions statement through automation for every new service you spin off. The idea is that you take in a template, and replace company name with Startup (abstracted out with getCompanyName()) and product name with AprilFoolsDeuxExMachina (abstracted out with getNewProductName()).

A temptation to ensure nobody accidentally changes company name is to guard it with a test. In this case it is literally the equivalent of two-passwords-matching case.

You would do

“Startup” == getCompanyName();

What is this test ensuring? That the company name is right? Who’s to say you didn’t get it wrong in the test? When the company gets acquired, is the test wrong or the code wrong?

Would it be better expressed if we simply wrote two identical functions (a sort of two-factor authentication) that increases the barrier to entry for modifying company name, rather than making it a test “failure”?

There are many more examples. This is simply an observation I had when reading nearly any code… that chasing code coverage looks very good in principle and on paper, but there are times when an argument needs to be made to not add a test, if it doesn’t answer either (and especially if it answers neither) of the two questions above.

 

March 4, 2014

JJ Abrams is the real childhood rapist!

Filed under: Uncategorized — archisgore @ 3:02 am

Admittedly bad title and major clickbait. Also sure I just made it to the top of the PRISM program. (How goes it NSA? You got cool jobs for someone who wants to wear a tux, jump out of airplanes, and snow board into the ocean and covertly sneak into enemy territory? Call me – feel free to remote activate my phone if I forget to turn it on. No biggie.)

Sooo….. yeah, the title is in response to “<Blah> defiled my childhood” kinda comments. 

Star Wars and Indiana Jones have a mass following that caused major outcries when they put a swinging monkey in there (oh and also the CGI things to accompany him.)

The one that really really really pisses me off, is what Abrams has done to Star Trek. He claimed he wanted to bring a little bit of Star Wars adventure to Star Trek, and what he spit out is much like Episodes 2 and 3. I actually rather liked Episode I (in comparison) because it had a story. I walked away remembering what they wanted, what they cared for. In Episodes 2 and 3, I don’t recall the plot. I find no “buy in” into what’s going on. Do I care about who wins? What do they want? What are their motivations?

Star Trek from 2009 was okay….ish, and yet sucked. Star… Trek Into Darkness, really got on my nerves though for various reasons. No, it’s not the lens flares.

1. Don’t Go “Beyond the Fans”

Fans are fans for a reason. I’m SICK of studios trying to go “beyond the fans”. You want to know why The Chronicles of Narnia: The Lion, The Witch and The Wardrobe really really worked? It catered to fans. You know why that works? They are fans for a reason. That reason is why the book became famous. It goes to argue that that may be the reason people would want to watch the film. Whether it is a portrayal of a character, a particular message, or some entertainment.

We see this happen repeatedly – does anyone remember the plot to the last couple of Harry Potter movies? What were they doing? Why? Who was involved? The last Narnia movie had the same problem – that began with Prince Caspian. Why were they on that voyage? What the heck was going on? Who are these people I’m watching? Why must I care about them? The books were bluntly allegorical, and you know what? I loved them for it! I don’t know if it is the entitlement generation or just idiots, but WE DO NOT HAVE TO LIKE A CHARACTER to like the story. You know what made 1984 great? It certainly wasn’t the likeability or relatability of the characters.

What makes stories great, is honesty. The Chronicles of Narnia are allegory. That’s what made them famous. That’s what adds the mystery and magic to them. Father Christmas giving gifts. Aslan sacrificing himself. The Emperor over the Sea. A movie done honestly to the characters becomes interesting. You don’t have to AGREE with Christianity to be compellingly interested in finding out what happens next. I appreciate that the world is a larger place, and more non-Christians watch Hollywood movies than Christians, but once again, the entire point of the books is lost. The books aren’t about four kids living on a ship. The books are about four kids overcoming sins and challenges and doing what’s right. They are what they are and that’s what made them work!

You think Star Trek is about science and anti-religion? You’re stupid – because Star Trek has more tolerance to spirituality, religion, admiration and respect for history and the our past then you’ll ever know. Since this entry is ABOUT Star Trek, the whole thing explains how Star Trek stopped being Star Trek when they went “beyond the fans” – the very fans whose fanboyism got the budget approved to make the damn movie! It was like Abrams was bailing out the non-fans with Fanboy cash. He knew we’d pay, so he made a space-cowboy adventure movie, gave the characters the right names, and titled it Star Trek. Fanboys paid for the whole enterprise (get it? eh? eh?), and others enjoy the “pew pew” space fights.

2. The characters have to be better than us

Last night, I was telling someone why I hated the film Gravity. I trust Sandra Bullock is an excellent actor. I don’t trust any astronaut would behave in that manner. When her O2 is running low and she’s hyperventilating, I wanted to see her passing out. You know what makes characters relatable? When they show us how we’d feel. You know what makes characters inspirational? When they show us how they overcome it. This comes up in my scuba diving world all the time – modern-movie-like emotional attitude cannot overcome physics or physiology. Your being “more badass” than I am, or you having “more willpower than the puny character”, doesn’t make you immune to a shallow-water blackout.

I understand that it makes us feel bad, and you don’t want a fan feeling inadequate do you? Well yes you do! That’s what made Star Trek great! Star Trek was not showing me how Captain Kirk is the same whiny crying emotional wreck that I would be. Star Trek was showing me that Captain Kirk was better than me! It made me feel bad, but it told me what I need to do.

That is precisely what is wrong with Gravity. The academy needs to set up a demo-reel award to save us from this bullshit. I totally imagine Sandra Bullock can emote. Create a demo reel, show it to the academy and get your damn award. When I want a story about the horrors of space, I want to see a role model. I know that Sandra Bullock and Catniss Everdeen and (I can’t believe I’m saying this, and that it’s going to be immortalized on the internet) Bella Swan appear to be feminist role models, and yet we’re moving ass-backwards on feminism! They are the opposite of strong female characters, and we can’t debate it because what am I? Anti-feminism? Bring it!

There is a reason, Apollo 13 astronauts calmly said, “Houston, we have a problem.”, instead of screaming, “Holy shit the O2 tanks just blew. All my sensors are down. OMG OMG!!!! OMGosh…. Please update my facebook! OMGosh!!!!” It is also the reason, I am not allowed to dive in Caves without proper training.

Gravity was supposed to show us the kind of person who stays calm when her Shuttle’s shielding tiles have broken lose. THAT is what good acting is – to demonstrate the frightening circumstances, and how our role models overcome them.

Kirk not shooting when the rest of us would shoot, is what Star Trek was about. Kirk not going on a revenge mission for Christopher Pike, when the rest of us WOULD, was what Star Trek was about. Yes, it makes us feel like shit. It makes us realize we are cowards. It makes us feel slightly guilty that had I been in that position, I would go on a revenge-fuelled murder-spree across space. And that is why I don’t command the NCC-1701.

Kirk was the youngest starfleet captain…. after only more than a decade at the academy. Abram’s Kirk becomes the captain for… huh? It doesn’t make Kirk look great, but it makes Starfleet look stupid and incompetent. (Same criticism of Gravity – rather than admire and respect the NASA training program, their program directors and all the awesome stuff they do, I began to question how and why they put a biologist or whatever in space to replace some PCBs.)

Star Trek built a generation of people who studied physics and mathematics and biology and medicine. They aspired to study hard and work their ass off, and be a “walking stack of books” so they could be like Kirk. Abrams’s movies tell kids that if they’re cocky and stupid and go on revengue-fuelled murder-sprees across the Galaxy, they’ll get to command starships. Did you ever wonder what impact that would have on alternate-timeline Picard? You think the cadet who studied his ass off for years, studied military strategy, studied philosophy so he would understand the Prime Directive better, commanded other ships, is going to be inspired that a 3-year-non-graduate at the academy got command of the Federation Flagship?

3. Star Trek shouldn’t be idolizing rebellion against the principles of the Federation!

This stems from the above. What would we do if Khan attacked us?

Who’s Khan you ask? Who knows – some British Dude also known as John Harrison. Did that help you know who Khan is? Me neither. Why would he go by John Harrison? Why would John Harrison tell me his name is Khan. Is that supposed to mean something to me? Why was there some dramatic-reveal music behind it. I know plenty of people named Khan – Shahrukh Khan. Salman Khan. Aamir Khan. And now John Harrison Khan. I don’t get “grand reveal music”, when someone tells me, “I’m Khan.”

If Khan attacked me, I’d simply attack back. When that big reveal came in “Into Darkness”, I had no idea what I was supposed to feel and why Benedict Cumberbatch was telling people his alias. All they had to do was call Old Spock, and figure out what to do. All the character development, all the experience gained by original-Spock is unnecessary. When Kirk says, “I’m sorry” to his crew, what is he sorry for? What has he learned?

Let’s go further back. After that cool opening sequence featuring the beautiful Enterprise underwater, a sequence ruined by humans in it, you get to watch Pike being all pissed about violation of the Prime Directive. Do you know what the Prime Directive is? Do you know why it’s important? Did you question Kirk’s motives? Did you ever wonder what you would have done when you saw a culture about to be killed by a volcano?

Once more, we’re treated to a depressing future. Instead of looking forward to a hopeful future run by a mature Federation Council that has learned from a great deal of historic mistakes, I have to look forward to a dogmatic idiotic agency that creates all these buzzkill “rules” and then have a senior Admiral mildly scold my favorite hot-shot captain, after having made him a Captain without proper training to start with. Let Kirk do what he wants Pike! Don’t crimp his style with this Prime Directive bullshit!

I’ll bet anyone not familiar with the series was totally rooting for Kirk without knowing why. Kirk didn’t even mention breaking the Prime Directive – and yet you rooted for him,didn’t you? Admit it!

In the series and TNG, entire Episodes are dedicated to court hearings on the Kolvoord Starburst and what a fundamental duty of each Federation officer is. Every time the Prime Directive is broken, there is a sense of loss – a sense of betrayal of the values the Federation was built on. Entire monologues are dedicated to commentary on Integrity and Honesty.

Now I understand rebellion. Rebellion is cool. That’s Star Wars. The United Federation of Planets is not Palpatine’s Galactic Empire. You’re working FOR the good guys. Abrams got so carried away up his own ass with Alias, that he can’t tell the difference anymore.

You were supposed to root against the Galactic Empire. Even George Lucas had trouble depicting the Jedi as dogmatic in the prequels. The Jedi were the good guys. They didn’t force/enforce their views on anyone. Anakin choose to join them. He ASKED to join them. Instead of Anakin being “seduced” through a complex and cunning plot, we saw a whiny ungrateful jackass killing Padawans.

The Federation will have bad Apples. You are supposed to fight against the Federation to UPHOLD the values that members forget. Kirk was supposed to rebel against those who questioned the value of the Prime Directive. Kirk was supposed to rebel against those who advocated going after Khan and killing him. The last thing Kirk was supposed to do, was rebel against the people calling for moderation and reason.

4. Characters have to take responsibility – that makes them GREAT!

You want to make Kirk great? Show us Kirk trying to figure out how to defeat Khan. Show us current-spock out-thinking Khan’s strategy. Asking old-spock for a cheat-code makes no compelling Star Trek. Once more, I get plenty of good pew-pew space-laser action in other movies. First, I had no idea why this one guy they had in the brig should be hated. His people were held hostage and he was threatened to do the Federation’s bidding. If your kids were held hostage on the home-planet of the Federation, with thousands of light-years of Federation space in every direction, and you killed your hostage-takers, would you go through the nuance of figuring out the one Admiral who’s doing it, vs the others who aren’t? (Hey there NSA, must have tripped your PRISM filter again with that sentence. Remember that job I was talking about? Call me!)

Then let’s come to the punchline I was building up to – if Benedict Cumberbatch played a guy called John Harrison, would you have rooted against him still? Reedit the entire movie, to remove that one scene where he announces his alias, and after that shot redub every mention of Khan with John (say it with a thick american accent, and you won’t even know the lip-difference.)

Let’s watch the movie in this form. You got any clue as to who the villian is? I’m not sure I wasn’t rooting for a bunch of Federation ships coming around to arrest Kirk, John and that crazy Admiral Marcus.

Don’t even get me started on Carol Marcus – a previously wise educated respected scientist working on the Genesis project.

Without Old-spock mentioning it on star-FaceTime, would you have known john was the most dangerous enemy faced by the Federation? How? Why? Because he was trying to free his hostages? Watch the movies Taken, Ransom, Taken 2, Commando, etc. Begin rooting for all those henchmen who got killed because this one NSA/CIA spy who’s done horrible things goes and kills them to try to free his family. Is violence the answer? The way John should have somehow trusted that other Admirals in Starfleet are not necessarily evil (because John is all about walking around in public with the freedom he has, so he gets to meet and know the motivations of various Starfleet Admirals.)

Alright fair enough – I think I’ve got to begin taking back some of what I said about Star Trek – it did make me think. I’m sure I don’t know anyone currently who got the nuance but look – Space Lasers! Pew! Pew! Pew!

 

RECAP:

So here’s recap what kids learned out of Star Trek so far:

1. Don’t you study hard about civilizations or whatever, that’s bullshit. Just do what pops in your head. Cause that’s how we roll! 

2. If you reboot your computer during a test scenario, your instructors will be totally cool with that. It’s not like they’ll simply forfeit the results, and ask you to take the test again, because when has that happened? Next time you’re taking the SATs, just make sure the lights go out for a few minutes, copy all the answers from the next guy, and watch as those results are held perfectly valid by the ETS. You may be court-martialled in front of the entire population taking the SATs that year, to ponder the philosophical reasoning behind the test, but a power blackout? Nah, it’s too much trouble to simply make you take the test again. What are we, barbarians? God knows Kirk doesn’t have time to take it more than once… oh wait.

3. Starfeet is a bunch of fools who put in buzz-kill style-crimping regulations and give them important-sounding names like the “Prime Directive”. Don’t worry about it.

4. When you’re questioned, as a heroic officer representing Humanity and the Federation of Planets to other races, just lie about your violations. Also, make sure you criticize your alien/foreign for being honest – cause that’s not how we roll! Those foreign people with their principles and bullshit! Meh. Heaven’s knows, I want to know my alien friends display loyalty to mere acquaintances on their ship, because older-versions told them to, rather than demonstrating integrity and honesty. (Heck, let’s go after Khan and kill him because he was trying to save his people and he was practically being held hostage, and under great abuse by any definition of the word.)

5. Old-Spock always helps when they’re in a jam. New-Spock and New-Kirk aren’t quite intelligent, capable, witty or competent. It’s not like THEY found ways to get out of tough situations. Just ask Old-spock when in trouble.

6. Try not to study. Don’t train for anything. There’s no reward in that. Just hang around a ship until everyone who outranks you dies, until you get command by default. If you spend a couple of decades studying interstellar history, politics, philosophy, war strategy, morality, ethics, etc. you’re not going to be invited aboard the Federation Flagship. No way. Hang around San Francisco as random crap falls on it from space.

7. If there’s a woman around, she’ll undress to under underwear at least once in the next few hours.

8. That Vulcan friend of yours who tends to display far more aggressive emotions than you do? Yeah, keep teasing him about his lack of emotions. Remember that one time he lacked so much emotion he beat the crap out of his school friends, Kirk, Khan? What a lame jerk that guy is huh? Hehe….

9. If you work for an agency that is founded on Principles and Values, make sure you rebel against them every chance you get, or go to an arbitrary planet to create a chance to rebel. Look to teenagers for cues on how to find such opportunities.

You’re having trouble hating George Lucas or Steven Spielberg now, aren’t you?

February 7, 2014

Diving accessories nobody will tell you about

Filed under: Uncategorized — Tags: , , — archisgore @ 1:42 am

Let’s start with the Home Depot link! :-) Yeah – let the jokes begin. (I work for Amazon.com for the rest of you to appreciate the jokes.)

http://www.homedepot.com/p/Husky-X-Workhorse-Workbench-17185155/202021304

and

Magna Cart Ideal Hand Truck

Magna Cart Ideal Hand Truck

Buy from Amazon

In the diving world, people are idiots; it takes a very particular kind of nutjob to be a diver in these cold parts, and you can’t expect well-adjusted normal regular people to be active divers. It’s a lot easier to buy a pair of skis and have a beer on the slopes.

So if you’re around, your dive shop will get into great debates on the cost and economics of O2-compatible regs and getting O2-cleaned valves, and the purchase of top-of-the-line Halcyon gear, or the effectiveness of a radio transmitter on your regulators.

What nobody told me for the last two years was, before you sign up for your first dive class, go to a Home Depot and buy that table above. Just do it. Don’t sign up for class without it. I found out last Friday, that there exists a foldable hand cart which I can use to carry around my doubles and other random gear.

I am building out killer muscles lifting all that stuff, but dear god, is it painful to put on a pair of doubles when you own a regular sedan. The difference between upgrading your car to a huge truck, and buying a small table from Home Depot, guess which one you want to do upfront?

Don’t get caught up in the lies about that fancy Liquivision X1 or whatever. The best kept secret your instructor isn’t telling you, is a 40-dollar table and a 35 dollar hand truck! I’m having posters printed and putting them out in my favorite dive shop soon!

January 30, 2014

When a doctor wants to visit a doctor…

Filed under: Uncategorized — archisgore @ 8:30 am

Funny thing happened today. My Facebook friends will have followed the thread, which I ultimately deleted. I asked for a recommendation for a web designer who can build me a site. The ask is as clear and simple as it gets. I don’t think for one second you’re assuming it has hidden subtext.

In response, I got among other things, recommendations to various hosting providers, questions about what the website is about, knowledge on various hosting tools, a person’s experiences with MS Word, an (admittedly educational) lesson on OneDrive, and (entirely my fault) a minor diversion into philosophy.

It got amusing, and then became irritating. I did finally find someone to build me a website, but god damn was the experience jittery.

When a Doctor falls ill, beyond the obligatory and beaten-to-death joke (or irony of it), you wouldn’t be too surprised that they needed to visit a doctor. If a web developer just doesn’t want to go home and manage web pages all over again, and instead wants to hire someone to do it, you get the equivalent of references to medical devices, textbooks on diagnostics and names of medications. What is up with that?

I’m sure the city’s storm-drains maintainer still goes home and calls, a plumber or something to fix his faucet. And I’m sure the city’s power operations manager doesn’t go around wiring his own house and the houses around him. And I’m sure my barber goes to another barber to get her hair done.

What the heck was that on Facebook then? Not to brag, but I know what a website is. I know how HTTP works. I know what a webserver is. I know what a CMS is. I know what caches are. I know how hosting providers work. I know what VMs are. And I know what wordpress is. How does a simple request for someone who’ll build me a website, turn into references to tools and what one guy does with MS Word at home? If I asked for a house cleaning service, you wouldn’t send me references to cleaners and mops would you? Please tell me you wouldn’t! Because that would be a pretty horrid world to live in, and you’d be major pricks!

As much of an Open source supporter as I am, I never tell people “Free” software is “Free-of-monetary-cost.” I know it’s not. When half your commentators are from Microsoft, one would assume they know that as simple as something may be, the integration cost is, well a cost. Heck all their money comes from building amazing software that is 10x easier to use compared to Linux, _AND_ being able to sell a partner service that’ll integrate it and configure it and put the finishing touches.

Why am I denied the ability to rent the same service? Even if getting a domain is as simple as going to this site, entering it, finding it, registering a credit card, setting up a CNAME, setting up a backing webserver, and so on, I simply may not want to do it! Is that so hard to believe?

Older Posts »

The Silver is the New Black Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 1,119 other followers