What's it all about, Alfie?

Linus Torvalds is in the news again this morning, and I'm glad to see he's now aware of the effect he had on people, it got me thinking about git and I thought I remembered that he wrote the first version of git after something happened with the license on the SCM tool he was using on the Linux Kernel. So I hit Wikipedia, and sure enough, there was a license issue with BitKeeper, and so Linus wrote the first version of git.

What I hadn't remembered was the timeline - and that's what amazed me this morning:

• 3 April 2005 - Development Starts on git
• 6 April 2005 - the git project is announced
• 7 April 2005 - git is self-hosting
• 18 April 2005 - first merge of multiple branches
• 29 April 2005 - performance target is achieved: 6.7 patches per second
• 16 June 2005 - linux kernel 2.6.12 release is managed by git

So a couple of months to get a SCM that hosts one of the most influential codebases that currently exists... that's more than impressive... that's down right amazing.

Think about all that git has effected... GitHub, BitBucket, GitLabs - there's an industry built up around it - that's wild to think about. Sure, the guy may not be someone you want to have over for dinner, but what he accomplished in a few months was nothing short of amazing. And all of us in the tech community have benefited from it.

There is something to be said for talent... it's not necessarily sitting in the prettiest of packages, but we would all do well to look past the packaging, and try to see the real value under the covers. It can be revolutionary.

I've just finished a book that I really enjoyed, but I'm glad I read it last of the three - in fact, I'm glad I read each of them in the order in which I did. It made for a much smoother reading experience - because I started with Pragmatic Scala and this was really based on the fact that we are using Scala in The Shop, and as such, I felt it was important to get up to speed on the language, and the Pragmatic Books have always been pretty good, in my experience.

Well, this was a fine book on Scala, but I have to say, I'm stunned that Scala is as popular as it is. I understand that one of the key design goals of the language was to be a pure Object Oriented language - and as such things like static methods and variables are not allowed in the instance variables, but they solve that with partner classes, and that's OK... but it is confusing for many folks - simply because most coders are not going to have a Theory of Languages in their past.

Still... Scala is a language we use at The Shop, and that means for better or worse, this is something that I needed to know. The next book was a little more fun because it was all about Xcode. In Xcode Treasures, the author walks through the tool not the SDK. This is nice, because in my recent work, I've re-written my crypto quip solver to Swift 4.2, in Xcode 9, and the times are really not horrible - compared to ObjC and Ruby, but Clojure still wins the speed race, but that's to be expected.

And while I spent plenty of time in Xcode quite a while ago, it's nice to see how much progress has been made in Xcode recently. The handling of assets like icons and images, and being able to load them without worrying about the resolution is really nice. Also, the entire Gatekeeper and Code Signing is now simple, and it used to be a pain. That's a great relief.

So this was a really good chance to catch up on a lot of the capabilities with Storyboards in Xcode and the scripting and such... very nice book. The final book was Mastering Clojure Macros and this is one I've been trying to get through for quite a while - many months, in fact. It's not a long book, but it's dense, and it takes time to make sure you understand the concepts because macros in Clojure are hard enough, and some of the examples are compact - as Clojure is want to do, and that just makes it all that much harder.

But the book was just amazing! What a great study of the subject. This was one of the few topics I really wanted to get better at with Clojure. Yes, I'd like to get a little more into spec, and core.async could be very useful if you're making small, independent apps, as opposed to big, multi-host apps where you typically share messaging queues, etc., but still... macros are in everything when you really get into things and I have been able to do quite a bit with them to date, but I wanted to know more.

Of the three - they are all worth reading - if you want to learn the material, but I really enjoyed the last two far more than the Scala book, but that's because of the subject - not the book.

I've worked with folks that identify requirements for a system, or a group of systems, that are going to be significant issues for the system - and might be used in maybe 10-20% of the cases that we'll run into. Yes... there is no doubt that if it is needed, then having it integrated into the very core of the system will make it very easy to add. But for those times when it's not needed, it's an unnecessary complexity that will cost every project in many little ways:

• Increased Dependencies - there is no need to include things that aren't used, but if you make it part of the scaffolding in the web app - it's there whether you want it tor not.
• Training and Discipline - since this is not natural for Javascript, it's going to mean that the developers that do this coding will have to be trained not to break the rules of the new scaffolding, and they will have to have more discipline than they'd otherwise have to in order not to violate a rule of the system and endanger the system.

and while this doesn't seem like a lot - it's really quite a bit when you're trying to bring in large groups of decoupled web developers. They don't mean to be careless, but UIs seem to get re-written about every nine months to a year, as the new Javascript framework is released, and if not compatible with the old. So it's almost like the UI code is throw-away code.

Not that I'm a fan fan of throw-away code, but I do recognize what's happening in this industry, and that's just whee things are headed. Evidence is hard to ignore.

So... when is a requirement not really a requirement? If it's for a small percentage - really it's hedging a bet that this will be needed. Because if it's never needed, or has limited need, the cost will far exceed the benefit, and this will be seen as a massively complex system. No one wants that.

For now, I'm being told it's a requirement and that means in it goes. If they are right - then it'll be one of the best projections I've ever seen, and they will be heralded as a true visionary. But if not... well... it could easily go the other way.

Gruber was poking fun at the MoviePass folks not being able to buy tickets for it's users, and brought up this fantastic faux commercial that aired on Saturday Night Live years ago, and it just made me laugh. It's the "Volume" at the end that really got me - still does.

One problem with changing an organization is that the Old Guard will do just that - Guard the old ways, and make it increasingly more difficult to make the changes that are part of the overall transformation of the organization. Change isn't easy, change can be annoying, horrible, scary, and painful. But an organization is similar to a living thing, in that it has to adapt (change) with the times, or it's going to face extinction.

This commercial is all about failure on an epic scale. It's something we've all seen in comics, stories, movies, and most of us - real life. It can be hard to see what you are doing when you are doing it - because the motivations are often set long before it comes around to execution. But it's there. If you can step back for just a second to take a look.

Well... it's the first day at the new job, and I've got a lot of good feelings about this place. First, it's about giving back - at least a little to the folks that grow all the food we eat. After spending a lot of time making "business" - it's nice to be a part of something that is really making a thing. Nice.

Then there's the idea of possibly staying with Clojure - there's a good bit of it here, and it's supported at the highest levels, and that's both a good sign, and a nice chance to keep doing some of the really good work I've been doing for several years now.

I have no idea what will happen… it’s only the first day, but I’d really like to think that this could be a place to stay for a while. I’m getting tired of the stress of the last year.

I was just sitting in my office at home and heard the sound of a train rolling by my house. I can't be 50 yards from the tracks, and I just love it. When I was a little kid, I'd visit my grandparents in a little town in upstate Indiana, and from the room we'd see in, we could hear the trains go by. They were a lot further away than the trains that run by my house, but I loved the sound then, and maybe I love the sound now because of what it meant to me then.

Memories are powerful things. I'd like to hold onto the good ones, and let go of the bad, but life isn't like that. You have to accept the bad ones, and enjoy the good. That's what life is about.

As part of this continuing project at The Shop, one of the things we're going to need is to be able to put URLs in emails and have the user click on them, and have it take them right to the document in question. This means we need to have the index.html page accept a query param of the ID of the thing to load. Then, if we get to the page, and this query param is there, then we load the requested data, if not, we put up a blank page, and then let the user search for the document they want.

Seems simple. If we can get the query params from the URL in Javascript.

Thankfully, someone posted this lovely little function:

  /*
   * This function extracts the provided query string from the URL for
   * the page we're on, and it's a nice and simple way to get the parts
   * of the URL that we're looking to see if they provided.
   */
  function qs(key) {
    // escape RegEx meta chars
    key = key.replace(/[*+?^$.\[\]{}()|\\\/]/g, "\\$&");
    var match = location.search.match(new RegExp("[?&]"+key+"=([^&]+)(&|$)"));
    return match && decodeURIComponent(match[1].replace(/\+/g, " "));
  }

Then we can have a little script block at the bottom of the index.html page, after loading all the javascript libraries, that checks to see if this parameter is being provided:

  // when the page is done loading, then load up the form
  var lid = qs('loan');
  $( document ).ready(loadLoan(($.isNumeric(lid) ? lid : null)));

This snip does everything we want - checks for the numeric value, and if it's there, uses it, if not, shows the blank page. Very nice.

I've been working to build a little collaboration tool at The Shop with a clojure back-end and a simple Bootstrap front-end. I have to admit that Bootstrap and Handsontable are some amazing tools, and I could not imagine doing the project without them.

Part of this was to have a simple 'Search' feature in the top menu bar where the users could input the known ID of a document to pull up, and the system would do it. Thankfully, Bootstrap supports this capability nicely:

But the problem with this is that it's put in the page as an HTML form:

  <form id="search_loan" class="navbar-form navbar-right" role="search">
    <div class="form-group">
      <input id="loan_id" type="text" class="form-control" placeholder="Search">
    </div>
    <button id="find_loan" class="btn btn-default">Go!</button>
  </form>

so that when you hit 'Enter' in the text box, or click the 'Go!' button, it performs the POST, and your code either has to be ready for the POST, or you have two refresh of the data - and that's not simple or clean. The solution is to intercept the form submission and hijack the event to do your bidding.

At the bottom of your HTML page, where you load all the javascript libraries, you can put a little script block, last of all, and it'll do some cool stuff:

  // set up the form components to work as we need them
  $("#search_loan").submit( function(e) {
    e.preventDefault();
    loadLoan(document.getElementById('loan_id').value);
  });

this little bit of code will capture the form submission event, prevent it's default behavior from occurring, and then call the loadLoan function with the contents of the text box in the search field.

Given that this function is what you want to have happen, this will make the search box work just like you want. All from one page, no redirections, no calls to refresh the page. Just load up the data on the search. Very cool.

Today I spent a good bit of the day trying to figure out how to authenticate with Twitter's OAuth 1.0 system, and I think I'm getting close, but I'm still a bit away because I don't control these accounts, and the sheer volume of ways to authenticate on Twitter is daunting. Let allne the different APIs.

There is the client-facing Tweets API, and then there's the Ad Server API, and it's not at all clear that there needs to be different authentication schemes for these APIs. But it should be clear that access to one set of APIs probably should not guarantee access to another set - and maybe they handle that in the authorization, but it's not clear from the docs I'm reading.

And speaking of docs, wow... these are really something else. There are at least four ways to authenticate, but they ask people to use libraries - that they don't provide. Sadly, I don't see one that does 100% of what I need, but I do see an OAuth 1.0 library, but the Client ID and Secret are nowhere to be found on their site.

So clearly, I'm missing something.

What I believe is that you have to create an App that then gets you the redirect URL and ID and Secret. There were none defined to base a new one on, and so I sent off an email to the Twitter representative to see if this was, indeed the preferred way.

While I was waiting, I decided to try and make an app. Yet in order to do that, you need to assign a mobile phone number to the Twitter account, and I can't really do that because the account is not mine. SO I sent another email to the relationship folks in The Shop about that.

In short, it's just a waiting game. But it's also so much more of a mess than the other systems I've been integrating with. Wow...

This afternoon I saw a tweet from Heroku about them adding Redis to the add-ons for their service. This just a few days after their announcement that Postgres was available for the free tier, and the new "Free" tier for apps. They are getting aggressive with what services they are providing. This makes a ton of good sense to me, as I'm a huge fan of redis from clojure, and this makes all the experience I've got in building apps directly transferable.

While I know the Free tier isn't all that great, the idea that there is a Free tier is amazing, and it means that I can write something and throw it up there, and as it's needed, I can scale it up. Very cool. They also have a hobbyist tier that's only something like $8/mo. - similar to GitHub.

If I needed to be firing up a web service, it'd be clojure, redis, and postgres - all on Heroku. What an amazing service.