isn't quite ashamed enough to present

jr conlin's ink stained banana

:: Dear LinkedIn,

Some People are laughing.

Some people are crying, singing, getting coffee.
Some people are playing with children, watching them grow up, get married and have kids of their own.
Some people are traveling to places they know, or have never seen before.
Some people are meeting old friends, new friends, and strangers.

Some people are scared, depressed, joyous and comfortable.
Some are reliving their past memories, dreaming about their futures or just living in the moment.
Some are hungry, others full and neither knows the other.
Some are living far from others, some are right in the thick of it all.

Some are looking for bears, looking at bears or being eaten by bears.

Some people are dreaming, others awake, and others somewhere between.
Some people are greeting the new day while others toast the sunset.
Some people have just opened their eyes for the first time.
Some people have closed theirs for the last.

And some people are looking at my profile.

i could care less.

Stop telling me.

:: Javascript, the New PHP

A couple of Employers ago, i wrote a LOT of PHP. To be fair, i also wrote an inordinate amount of Perl and Javascript so feel free to make whatever assessment regarding my sanity you feel like. One benefit of being in a fairly heavy PHP shop right around the time that it was just starting to get commercially popular, was that said employer hired the guy that came up with it.

This was incredibly enlightening, not because he was as surly and jaded as myself (as well as a phenomenal security Paranoid), but because he openly professed that PHP was a server side layout language. If you were doing more with it than just simply laying out pages, you were doing it wrong.

Of course, you'd be forgiven for laughing at that. If you have even passing familiarity with projects like WordPress, Cake or the countless projects on Github or Sourceforge that are PHP based. The problem is that PHP is surprisingly easy to program in. It's exceptionally forgiving and has lots of capabilities that really lower the bar for new programmers. What that means is that folks who may not have years of experience or a firm understanding of the dangers to watch out for are trying to roll out very sophisticated applications.

There are loads of examples of this too. A perfect one is WordPress (yes, the very blog software i use right here). It's gotten FAR better, but even here there are lots of security gotcha's i tend to be concerned about. One very large one is that WordPress expects to be able to write to the directory it runs in. This is a HUGE "Not Happening" on any system i work on.

A well secured system runs any display server (that includes the web server) in a protected environment with limited privileges. On my system, the app server can read files. It will never be able to write, because when there's an exploit in the software, Bad Guys can't use it to alter files or execute scripts as me. This is how most sites fall, by the way.

So, how does all of this relate to the link bait title? Put simply, one of the biggest problems of PHP is that anyone can program in it. i don't want to sound elitist, but imagine if you could build a free car out of parts someone gave you. A bit of fidgeting, a little swearing and you've got something that rolls down the road. Chances are REALLY good, though, that you've not built a high end race car with proper safety considerations and navigation systems. Those take skill and knowledge that you may not have yet. You can certainly acquire it, but it's going to take time, experience, and learning from mistakes.

Same is true with software. It's not hard to put together a simple program that does some fun things. It's harder if you want other folks to use it. It's harder still if you want to build something that, like your car, won't actively try to kill you or anyone within 10 feet if you do something wrong.

PHP made the tools readily available and easy for folks with limited knowledge and skill to use. That's a significant accomplishment, but it does mean that there's a lot of code out there with no tests, no reviews and no support.

Javascript is clearly headed the same way. It's incredibly accessible, and products like node.js allow you to run Javascript on a server. The problem is that there are still going to be hard lessons not learned. Folks will still do silly things like open files based on parameters passed from outside, or use unescaped values in database queries, or even do uncached hits against remote servers. There are lots of anti-patterns, and even professionals make mistakes.

What's worse is that, like the PHP stuff out there, there's no way for folks to determine which libraries are "Safe" or not. Right now, folk often have no idea that many browser extensions are able to read and write to your disk or web pages directly, and have the ability to report those elsewhere. Libraries are like articles you read on the web. Sometimes the crazy is so deep it's nearly impossible for you to spot it, when you bother to actually read it.

We old, cynical, battle hardened coders need to do a better job teaching young coders how to write stuff. Sites like Stack Exchange help, but even those tend to have less than beneficial suggestions. Partly due to the fact that writing for devices isn't like writing web servers which isn't like writing web-apps, which isn't like writing databases, etc.

It's also noteworthy that there's a tremendous amount of broken things on the web. OpenSSL is a good example of this. Not because the underpaid and overworked devs are to blame, but because it's hard to get folks excited about working on infrastructure. Honestly, while i appreciate the fact that OpenSLL is finally getting rebuilt from scratch, i can only hope that the new code is thoroughly audited and vetted.

And that it's maintained and regularly updated.

So, what about those javascript frameworks that will be coming? i wonder what the chances are about those?

A bit more on this post since this has gotten attention.

i'm not bemoaning either PHP or JS. i actually like both of them. i agree that education is key, but the problem is that people generally don't like or realize they need education. Folks don't want to read several long, example strewn pages of well thought out prose. The fear i have is that since Javascript is becoming even more available than PHP ever was, the problem is going to get far worse.

So, maybe we need something that folks want to look for, like Goofus & Gallant for Coders, or Where's Waldo's Bug or something. Heck, maybe an Everything Wrong with This Code in 90 Seconds Youtube channel might work.

i help out a few friends that have websites. One of them grabbed a highly rated template for his blog. The template had a JS snippet at the bottom that collected a bunch of stats and did a remote execution. Mind you, there are lots of innocent reasons for something like that, but in essence it opened his site up for an easy XSS attacks. i'd wager that the folks that built that site consider themselves "experts". How do we convince folks like that they still need education?

That's the thing that i'm trying to get my head around.

And yes, i'm not going to propose a solution here. This is more a sketchpad for any future ideas i might have. Conversations are useful, even if they're just with myself.

:: Cost Effective Privacy

Joel Pett created a great editorial cartoon that shows an angry gentleman standing up at a climate summit yelling "What if it's a big hoax and we create a better world for nothing?"

i'm here to argue that having a solid User Privacy policy is one of the best way to reduce and manage costs you can have.


Well, let's look at a few points.

First off, let me note that i'm a server guy with a couple of decades of working with data and back ends. i can code in javascript, but you really don't want to see that sort of thing, unless you're a fan of horror movies. Nope, the crap i've dealt with generally is around taking data, transmogrifying it in odd ways, and puking it back up. For me, data is data, and there are certain rules one has to think about, the same way that a carpenter or architect thinks about building a house.


One thing you NEVER want to tell someone like me is that "Costs don't matter." Yes, yes they do matter. Unless you have an endless supply of money and manpower, they matter. Otherwise i'm going to set up a fully redundant, highly secure system of tiered databases, web heads and monitoring boxes that runs in at least 3 colos on 8 core boxes with max GBs of storage (both online and off). It'll be the most aweseome blog server you've ever seen, can withstand the combined attention of every social media site on the planet simultaneously, and will make your CFO reach escape velocity by soiling himself.

Even Google considers costs.

Where you make your tradeoffs matters, and one of the principal ways one does this is by managing the data you maintain. Storing everything is easy to think of, but absolutely ruinous to do. If you store to flat files, you'll pay in search costs later. If you store to Databases, you'll pay indexing costs now. What you want to do is store the absolute least amount of data possible for anything. Don't try to justify why you should cut something, justify why you need to keep anything. Hard. If there's any reason to pitch it, do it otherwise you're going to be drowning in a sea of noise looking for the few bits of signal you can.


This is the hardest thing for a lot of folks to get. One of the running statements for most products is "Ship It!". Go on reddit or stackoverflow and you'll see folks saying "Doesn't matter, ship it!" or some other term.

i hate that.

Let me explain. In my job. "Ship it" is the very first step. What follows is 5-10 years of "keep it running" / "can we improve it?" / "how do we fix that critical bug?" / "how do we transition users to the new service?" / "blah, blah, blah…" If you're lucky, your product runs on a platform that you can update, otherwise what got "shipped" is what's going to be live. Period, and anything wrong is your problem later.

This point is generally compounded by the folks who yell "Ship It" and send out their farewell notes a week after it ships. This leaves you with a pile of shippy code from the ship head and some angry users that have just been shipped on, and you holding the shovel to dig yourself and your future paychecks out of this pile of ship.

Privacy requires documentation. Clear documentation. Clear, understandable documentation with histories that outline issues and resolutions. Clear, understandable documentation in well known, easy to find locations. One should be annoyed by how much documentation exists for the code and how often you see references to it from within the code.

You also need that for ongoing maintenance, QA testing, release management, Load testing, etc.

So, if you have a product that doesn't have that already, you can tell the guys full of ship that they need to rein it in before they ship themselves and you wind up in deep ship.

(well, unless you're making a one use product that nobody cares about. In that case, you need to seriously re-evaluate your life choices.)

Johnny Law

Let's look at US law for the moment. As it currently stands, the Feds can show up at any time with a love note that basically says "Give us every scrap of all your user's data, and you can't tell anyone because Ter'rsts!" This bit of information will be disclosed at the least opportune time with the worst possible framing. It may have lead to Hitler bin Badguy eventually getting that parking citation on his Suppress-o-tron 2000 Battle Tank, but in the mean time, you will have shattered user trust and whatever good faith they may have had in your company. Folks will switch to other services or stop sharing and recommending your product. The paychecks will stop, and you'll be milking orphan tears for the Suppress-o-tron 3000.

Since the Long Arm of the Law is a bit grabby, it's better to know absolutely nothing about what your user is doing. When Agent Smith shows up with his pen register, he gets back client side encrypted blocks of useless crap. Ideally, blocks of crap that will take him well past the heat death of the Universe to decode.

Needless to say, if you're not in the US or plan on doing business outside of the US, you're going to have to deal with a whole host of privacy laws that will make you and your lawyer cry. In some areas, you'll have to tender any encryption method you have to the government, which means that even if you only see a key in passing, you'll have to hand it over.

Feel free to substitute "Ev1l Haxxorz" or other malicious, non-authorized parties, since if you do have to install a "secret back door" for "only authorized law enforcement use", understand that the credentials you provide will probably be stuck on a post-it on a monitor and flashed across Fox News during some agency promotional piece. Well, that or distributed by a disgruntled former contractor. Feel free to use whatever mechanism you like, because it will probably happen. Do NOT presume that governments have better security than you do.


In short, keeping user data to a bare minimum, and well protected, not only is a good idea, it can save you serious money and hassle. It's not just good for users, it's damn good for you.

:: Introducing Quantcoin: The Currency You Already Have

QuantCoinSo, Crypto-currencies are quite the thing lately. Seems like there's a new one popping up every few minutes with some new angle. Unfortunately each of these new coins suffer from a critical flaw which results in loss due to threat or fraud.

That's why i'm happy to introduce QuantCoin©, the completely unstealable digital currency.

How can i get a QuantCoin©?

Easy, you already have one.

QuantCoin© uses a barely understood principal1 of quantum mechanics as it's principal. Unlike cryptocurrencies, it absolutely can NOT be stolen or misused. That's because there's only one QuantCoin©. See, QuantCoin©s exist in superposition, meaning that they exist in multiple points at the same time. That means the QuantCoin© that you hold is exactly the same as my QuantCoin©. If you were to somehow steal my QuantCoin©, you'd simply have the same coin you already own.

Amazing, huh?

What is the value of a QuantCoin©?

The way that QuantCoin© easily takes advantage of simple Quantum physics, it also uses the amazing advances in economics utilized by high speed traders. That's right, QuantCoin©'s value is based on futures trading.

How does this work? Let's look at an example. Let's say that you wanted to use your QuantCoin© to purchase a pack of gum. That establishes the value of your QuantCoin©. Bob plans on purchasing a new car. That means that Bob's QuantCoin© works out to be worth 64,000 times your QuantCoin©, meaning that in the future, your QuantCoin© will be worth 64,000 times it's value. This means that it becomes interesting to Larry, who's looking to buy a nice little home in Dubai, which raises the value of QuantCoin©s again. This means that the future price averaged for QuantCoin©s is now well over 1,000,000 when the QuantCoin©s are eventually exchanged using amazing "Minority Report" style interfaces that will require waving just about every body part, for the added security.

QuantCoin© is Green!

Quantcoin© doesn't need all that power consumption or complex math, because it works all natural, organic processes, and is made, right here in the good ol' . In fact, it works on the same principals that make meadows and pastures rich and vibrant ecosystems.

Isn't that amazing?!

And you can be part of it too, just sign up for my 3 day seminar and book series in the lobby and you too can be part of this amazing financial windfall!

QuantCoin©: Because Analytic Financial CryptoCybercloudbuzz to you, today!

1 "barely understood" means "by me". Obviously real physicists get this sort of thing, but hey, this is about marketing and folks buy those magnetic bracelets, so conning convincing them to accept this currency is a simple matter.

:: Programatic Paralysis

i started coding in Basic. Sometime later, Borland introduced TurboPascal, and i eagerly switched to that (carrying a copy of the compiler and IDE along with nearly every one of my projects on a 1.44 disk in my shirt pocket was neat). i later quickly adopted C, where i spent a good deal of time. After that came Bash, Smalltalk, Perl, PHP, Javascript, Java, Python, Go, and i'm sure i'm missing a few in there somewhere (Ada and Cobol both come to mind).

Suffice to say, like most every programmer out there, if it's based on Algol, i've probably worked with it and can learn the syntax in about 2 hours. Frameworks, of course, come much, much later.

There are folks i work with who eagerly jump from language to language. They herald the joys of Erlang and Haskel, occasionally noting the benefits of Lua.

Me? i tend to be a bit more pragmatic in my age. i have problems that need solutions. i understand that certain languages bring with them certain benefits, and there's an odd level of comfort with some systems that makes them favorites.

The odd thing was that recently i was thinking about writing a program for a task at home, and i kinda sat frozen trying to thing of what to use. This is a bad thing. i code to solve problems, not to just write code. i like to think that i am a bit more practical than theoretical when it comes to solving problems, so while i happily spend time to map out a problem space on paper before i start building, i want to be able to reach into the toolset quickly and get things running.

To that end, i think i'm going to clean out my toolbox a bit and focus on two languages: Go and Javascript.

Don't get me wrong, i'll still use stuff like Python, Bash, et. al where they make sense (Perl is a FABULOUS language for dealing with large blocks of text, and Bash fully proves the value of Taco Bell Programming, but for quick tasks: Go and Javascript.

So, why those?

Well, Go is fraught with issues and catches, but it works reasonably well, and is more than fast enough for most needs. It also straddles the happy middle ground of "interpretive" and "compiled" fairly well that dorking around in code doesn't blow hours of time trying to figure out what the hell just happened. It's also very much built toward being a back end for webservers, which i tend to build a lot of, so there's definitely that.

Javascript is the language of the browser. It's how you program a client to do things. i tend to write in Vanilla.js because the additional frameworks are more legacy than legit. Kind of like the reason that i use vim as my editor rather than something fancier.

Python, for all it's spiffery, seems to suffer from being a bit too spiffy. Packages and libraries are a bit of a nightmare and while it's nice as a prototyping language, there are significant problems going much beyond that. Likewise, Node.js (which is just javascript on the server) has a lot of interesting applications, but suffers from the same sorts of issues that mod.perl and most other server side scripting languages hit. i'm not saying that they're impossible to circumvent, but it's a bit like turning a VW into a high performance racecar. By the time you're done, you don't really have a VW anymore.

i'll also say that i'm not advocating that you should do likewise. Each craftsman has his tools, i just prefer having a smaller set. (Heck, my favorite knife is still one that i bought 25 years ago from Wacamaw Pottery for $20.) i'd just encourage you to review your tools and see if you might want to reorder the preferences.

Blogs of note
personal Christopher Conlin USMC memoirs of hydrogen guy Henriette's Herbal Blog
geek ultramookie

Powered by WordPress
Hosted on Dreamhost.