What’s new party people???
It’s been a long time.
I shouldn’t have left you…
Without a blog post to step to…
I’ve been on a social media hiatus for a minute and I’m ’bout to step out the shadows. While I do that I wanna talk about some new stuff I’ve been looking into. I also haz questions about how the new compares to the old. Let’s begin, shall we? Oh, wait… HAI, I IZ Cliff. You here because you really wanna party with me. So put your source code where my eyes can see. Now that we got that out of the way, let us continue.
I former coworker buddy of mine (he knows who he is, LOL) asked me about Flutter a couple of days ago. While it sounded new I kinda remember looking at it some years ago and thinking, “that’s sorta cool!” I never did anything with it at the time but now I’m taking a fresh look. I felt challenged by Mr. Coworker-friend and I thought I’d open this blog post by throwing down my gauntlet and saying, “I hereby formally acceptith thine challenge fine sir!!!” (I have no idea why I’m speaking in that form, by the way.) Flutter is a cross platform development architecture developed by Google that uses the Dart programming language. (Wow, it’s been a long time since I’ve done mobile!) It attempts to make UI development a breeze while facilitating the write once run everywhere philosophy. It’s sorta new but it also sounds like some other technology released in the 90s which was supposed to enable Write Once Run Anywhere. Anybody know what that tech was? I’ll give a hint, it’s still actively used to develop mobile apps! I digress, and I’m not hating, haha. I’m excited to see what’s going on with Flutter now. Look for one or two blog posts about how awesome or totally whack Flutter is as I attempt to dive back into mobile.
The thing that actually prompted today’s post was this Chromebook I saw on the Amazon truck this morning. This is not new tech. This is not even considered old tech. I honestly think it’s confusing tech. I’m confused because I never really used a Chromebook. What I wanna know is are these things practical? They remind me of the old Netbook things that were popular around the 2010-2011 timeframe. The more important question is how does a reasonably priced Chromebook of today compare to the ridiculously overpriced Pixel Chromebook from years ago? Are we at the point where a modern Chromebook is equivalently spec’ed to that beast? Also, why was that product so expensive? Was there any practicality in that?
I just did a little homework and apparently the original Chromebook hit end of life last August. The 2013 initial release has a 2560×1700 resolution on a touch display, a dual core i5 with HD Graphics and all day battery life. Even with all of these specs I could never understand the price tag as it smells like an overpowered web browser in a hard shell. I dunno, call me old school, but I feel a personal computing device (especially with that much horse power) ought to be useable for more than internet based tasks. In other words, it should have a ton of support for offline work, run a dump truck load of locally installable apps that can do anything from video editing to word processing to Minecraft.
Back to Chromebooks in general, Google has updated Chromebooks available to a smaller pice tag than the original. There is the Pixel Slate and the 2017 Pixelbook and apparently another Pixelbook in the making. The Google offerings are still much pricier than other Chromebooks on the market but in the end I can bring myself to care.
Chromebooks are not new. they are a five year old solution to a problem that people still have to this day… multi-device drama. Nobody wants to carry a laptop, a tablet and a Smartphone. Pixelbooks try to oversimplify the laptop problem while delivering a tablet that still doesn’t blow away the iPad. Ultrabooks also try to deliver a convertible laptop that doesn’t work as well in tablet mode. Even Samsung has tried to address this by supercharging their Smartphones and developing a cheap piece of small hardware you can use to dock into a keyboard/mouse/monitor. I guess the newest news about development in this space is the apparent absence of any clear winner or best solution.
Build systems are cool, aren’t they? If you’re a rookie developer you may not know what a build system is. It is essentially a set of programs, frameworks, and/or tools that turns the programming language you type in your editor into an installable product made up of 1s and 0s. In this space you have a variety of choices from Make/CMake and Ant, to Maven/Gradle/Rake, to npm/yarn/webpack/gulp. Each tool or combination is suited for a certain type of programming language and environment. Most of the newer options borrow from one another and employ the same basic concepts. However, there is a newer build system growing in popularity over the past 3-4 years. Buck Build is an open source build system developed at Facebook which takes a unique approach to not just building our source code but also how it is managed overall. It’s refreshing to see innovation in build systems. There hasn’t been much disruption since Maven entered the scene in the early 2000’s and began to overtake Ant. Buck is what some of the bigger companies use to manage huge projects. The interesting thing about Buck is that I believe it began life at Google (possibly as a series of hacks to the Gradle build??? …but I dunno, I’m speculating w/o research) and was copied by the original developers as they moved to other big companies. It has siblings, Pants (built by Twitter), Bazel (built by Google), and Blaze (the original project these were all based off of).
The most interesting thing about buck is that it operates on the concept of the mono repo. This is a single repository that contains all source to all projects/dependencies. This is the thing that jumped out at me as odd, disturbing, even outright disrespectful. You see, I have taken pride in evangelizing the idea of separation of concerns throughout most of my career. It seems to make sense and be applicable everywhere. Separate your model from your view from your controller logic, separate components/objects by interfaces, separate web services as micro-services, separate your white laundry from your color laundry, the separation of church and state, and of course most importantly separate your source into different repositories! Facebook and many others are now moving in the opposite direction and it’s taking a minute for this old-timer to catch up. (See how React combines UI HTML like syntax with JS controller logic? It was another similar shock to me.)
The modern big company problem is managing all of the thousands of projects and dependencies in an efficient manner. It always comes down to loss of developer productivity. How much time do you spend building your software versus developing it? See, in my mind it makes sense to have a separate repo for each component with established interfaces between each one and an artifact repository where dependencies are pulled from. That way you only run your compiler over the things that actually need to be compiled. If project A hasn’t changed and depends on component B which is changing frequently why do I need the source and compilers for project A? Why waste machine cycles spinning my compiler over all of the source? Apparently Buck addresses this in a way that is both unique and incredibly fast.
As much as I hate the idea behind a mono repo and as sour of a taste as this project left in my mouth initially I am super excited to try it out. I suppose this was the only real new thing I wanted to babble about today. (Well that and Flutter. I definitely wanna try Flutter too!) I haven’t been this excited about an open source tool since I discovered Groovy many years ago. We’ll see where this ends up.