What's it all about, Alfie?

One of the things I'm finally coming to terms with is that I am exactly who I am. Sounds silly - but here's the point that brought this up. A very good friend just sent me a link to a place he'd like to spend a long weekend on his next birthday. It's in the Bahamas, and it's a little cottage right on the ocean. It's secluded... it's small... it's beautiful, and it's got an amazing expanse of water to see. I don't think I could imagine a more amazing view - I'm sure they exist, but this was really spectacular.

And yet I know I'm never going there. Not in this lifetime. These last five years have been transformative for me, and I have come to learn things about myself that I was never forced to see, and I pray most people don't have to. But it's also shown me that the thought of a vacation is just relaxing at home. I know it's not what I'm capable of, but it's what I'm capable of enjoying at this point in my life.

Life happens. It changes us. We adapt. We move on, and we try to find the path that we are comfortable walking.

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.

Like so many other folks, Netflix and Hulu are bringing a lot of really interesting shows to my attention that I can't imagine I would have ever seen, and that's a very nice thing, but at the same time, many of the series I see on both the streaming platforms are already cancelled - without a word in the description that this is the case. At least then, I'm emotionally prepared to have this be the complete story I'll see.

One of the shows I finished recently was Jo on Hulu. And it was really very good. But in the description on Wikipedia, it was cancelled in 2013. It just showed up on Hulu. But 2013... folks... this isn't on the bubble... this is a 5 year old TV corpse.

I mean it's still really good, but there were questions that were left dangling. And I, for one, wanted to know. But I guess I'll have to make them up myself.

In truth, it was nice that it appeared at all, and I need to count the roses and not complain about it - but I do think it'd be nice to have something about the production of these series in the information on Netflix and Hulu.

At work we are in the process of generating the technical architecture docs for all aspects of the platform - from data and cloud deployment to applications and integrations. It is meant to be a complete picture of what we need to really be able to take the current products globally, and not crush us with costs. As a part of that, things are understandably moving a little slowly, as this impacts how people view themselves, and their contributions to the business.

If and emergency room doctor sees what they do as the number of patients patched up, then telling them to take a part-time position in Administration, then they might likely feel like that which makes them uniquely them is being questioned. They like the testing of new cases - you never know what could walk through the doors any second, and to many - that's a rush.

I was talking to my Boss about this as I was getting a little antsy about this as I wasn't really doing a lot - other than writing a few short docs about different parts of the architecture. It's needed, yes, but I'm used to being far more productive, and so just writing docs is not really on the same scale as delivering systems and having users react to them.

His statement to me was that this disconnect was normal. Perfectly normal. Yes, it can be frustrating, but it's a sign that things are starting to change. Patience is important, but not just sitting around. That there was a playbook that was being run, and it was just as expected.

Just like the 76ers - Trust the Process.

I felt a little silly. More than a little silly. I didn't really trust that someone saw all this, and was working on other things that had to be in place for the next set of changes.

Patience can also mean to trust that just because you don't see it - doesn't mean it's not happening. And that's hard... because it is indistinguishable from nothing happening. In both cases you can't see anything being done. It's tough.

But I'm going to trust the process.

Today I finally broke down and got the Sonos Playbase and Sub, and I have to say it's as easy to set up as I had hoped. I was a little concerned - because it was going to be using the optical audio out of the TV into the Playbase, but I really shouldn't have worried about it. It's nothing special these days - a simple (but very thin) cable came with the Playbase, and there was no way to put it in wrong. With a nice click it was in and the rest was easy.

Creating the 5.1 surround sound was very simple in the Songs app on my iPhone, and in a few minutes I was sampling the room and checking the balance, and it was just up and going. Very nice. Very simple.

I will say that my TV was doing about what I expected for a 4+ yr old set, and it was a lot harder to figure out how to turn off the internal speakers than I expected. But hey... I know where it is in the settings now, so it's not impossible, but it required scanning every menu on the TV to find it.

Now it's easy to watch TV, and then listen to music. Really nice sound for the living room.

The Shop is out of Diet Coke, and I can respect that they don't owe me a free Diet Coke, but it's still a little sad to see all the other drinks in the fridge, and not my favorite. So... assuming this was a Teachable Moment - I decided to try Coke Zero.

I can respect that people like this - I believe that it's the new Coke formulation in a zero-calorie formulation, but I could be wrong about that. I know I worked with a guy that preferred Coke Zero to Diet Coke, so I thought How bad can this really be? and gave it a try.

It's not horrible, but I'd rather drink water. It's something about the taste - but that completely explains why Coke has the two zero-calorie formulations. There's a real difference, and some don't really like the one. Go figure. In any case, I drank it - can't waste something like that, and then decided against having another.

Experiment done. Results obtained.

As a long-time fan of ObjC, and what NeXT and Apple have done with it, I was very interested when they released Swift 1.0 back in 2014, I was excited to see them move a little in the direction of Ruby. Everything in one file, more along the lines of a semi-scripting language, and while it wasn't complete to be sure, I was impressed that Apple was moving in this direction.

This week, I've been working on some architecture docs for work, and one of them is about the mobile platform space, and what we should be doing there to really increase the stability and speed of feature releases. Something that's been historically tough for NeXTSTEP and Apple with regards to ObjC is memory management and threading.

The days of retain/release were somewhat tough for new developers to ObjC to get right. It was really just about understanding the patterns for the use of retain and release and when to use autorelease. Once you had those down, you were pretty much golden. The run loop would pick up the instances with a retain count of zero, and didn't have to go looking for them. Memory didn't grow unless you retain-ed it and that was then pretty easy to spot with something like OmniAlloc.

Then Apple added Automatic Reference Counting and it got a little better, but we lost a few things in the mix. For example, compare-and-swap operations could not be known to have succeeded or failed by the compiler, so it could not know what to do with the retain count. I understood this, but ARC, as it was known, did a lot about removing the need for retain/release and so it got folks up to speed faster.

Losing a little functionality is something I can understand - if the overall gains are there, and there is at least some possibility of implementing similar functionality another way. This was disappointing, and Apple was clearly forcing ARC on the developers, as they had warnings about the use of retain and release.

Then I didn't pay a lot of attention to Swift 2 and 3, but I had reason to look at Swift 4 because of these architecture docs for the mobile platform. Wow. Apple has gone crazy and complex with Swift 4.

Several things have been added in 4.0 that wasn't in 1.0 - and some of them are probably quite nice. But at this point, the costs don't seem to outweigh the complexity of the language. But it certainly explains the Playgrounds as a concept - to get people writing code in a more friendly, less stressful environment.

Swift has lost the ability to use classic threading concepts like pthreads, and mutexes, and put in their place Grand Central Dispatch (GCD), which is a great idea for the kinds of "work unit" things that end up really complicating the code base when you have to do lots of different things - like most apps these days. But it shouldn't be used for little things... it's just too much overhead.

At least that's how tools should be used. You don't use a hand grenade to kill a mosquito, and you don't need Grand Central Dispatch to atomically increment an integer... or do you?

Yet that's what I was to come to learn from the docs I was reading. Apple is really pushing the concept of the main thread of the app, and that makes sense - it is the hold-over from the run-loop, and the single-threaded nature of classic Mac apps. This is a lot like the run loop of X11 apps, and a lot of the UI apps for a long time. But then why not abstract that thread from the programming model?

But there's more...

Because of the dynamic relocation of memory in iOS, there really can't be any fixed memory locations in the code. It's a cool feature, but now you have to add all the things in the language to indicate mutability and access control. They could have used this syntax to indicate which variables are to be fixed... or at least tracked carefully so that they always appear to have a stable location in the memory map of the process.

The end result is that Swift has become quite limiting in how to do things. You really have to go all in with their constructs. That would be fine if they had taken the extra steps and built in that level of abstraction. If they wanted Grand Central to play such an important role, then hide that role with some simple syntax. Make the 'jobs' that go onto the GCD queue simple and allow their specification to indicate their need for thread safety.

When I re-wrote some code from ObjC to Ruby, the project went from 2,700 lines to about 790. That's a significant savings, and makes code easier to write, maintain, and enhance. That's good stuff. But with the things that I'm seeing now in Swift 4 - I would not be surprised if the reduction to Swift wasn't at all like that for Ruby. I hadn't done the conversion at the time because Swift 1.0 didn't have the kinds of class libraries that I needed to make the conversion. Now, it probably does.

Some day I'll actually have to knuckle down and write the project in Swift and see what it turns out to be. I hope this is just a step along the way for Swift... just a snapshot of where they want to go.

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.

Today was my last day at the Shop. I was excited about leaving, but Management in IT did some Spring Cleaning and several of us found that we were dust bunnies in the process. I've spent the last two weeks transitioning all the work I've done to others that are staying, but in truth, that meant a couple of meetings because the transition was rather poorly planned. Their choice.

I'll get a nice severance out of this, and that's nice, and in truth, it was probably the best thing for me at this time... over the last several months I've been feeling that there's been an axe hanging over my head, and I even emailed the CEO on Christmas to ask if that's the case, then maybe we needed to make a transition plan to move me out.

His response was "No, you're just what we need!" and from that, I assumed that things were stable. That would be a poor assumption.

So, today is it. Nearly 3 years at the Shop, and now it's time to find a new place. The search continues.