One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike,
always wear white.
As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
So google news has let me know about the new HP smartwatch, designed by Michael Bastian (whoever that is), and it looks sharp. The Apple watch seems to be, if anything, a little overdesigned. Long-term, that's probably a good thing for Apple. Part of the beauty of the iPhone, and what's allowed it to change the way all phones are made, was that it left buttons behind and allowed you to create any sort of app on the machine's small canvas. That is, no matter what sort of inside access you get, you can't do much with a Head-to-Head football game's controls. You might squeeze out a marginally different race car game or something, but you're basically stuck. When the screen is as wide open as a blank slate, you have lots more flexibility. The Apple watch seems ready to do things we haven't thought of yet.
But what do you really want from a smart watch? There are only two things everyone wants, I think. The time (if only for historical reasons), and a place to read timely message highlights. I imagine that, like me, everyone has their own third. Me, I want built-in GPS so I can track a run without carrying a phone around.
Oh, there probably is a third everyone wants: Don't look like a dork wearing a calculator watch from the 80s. Let's face it, having a calculator right there whenever you need it is really kinda neat, but only during those times when you need it. The rest of the time? Doooork-E. Kinda like a chunky square watch with an oversized crown would look now.
This HP watch dodges the calculator watch feel awfully well. It doesn't have traditional hands like iHands I was kinda hoping to see implemented well, but it's close. There's a dedicated watch section on the face at the top left, which gives a similar feel. Here's an image from Gilt.
So the "watch widget" ring and the tick marks are permanent, but the hands come from the admittedly not retina-quality screen. Also note the orange arrows I added, pointing at the edges of the square watch screen. That's a little cheap looking, though not quite as silly as black bottom bar on the Moto 360, but in a similar, "We botched the implementation," vein.
The permanent clock ring makes that square a little less obvious, which is at least clever. That should visually break up the feeling of the watch as a square screen shoved into a round hole/face, which is pretty important.
Ultimately, this is a much nicer looking watch than Apple's, at least speaking conventionally in 2014. Kicks the pants off of the Pebble. Always tells time. Battery lasts a decent while -- apparently around a week. And it gives you a nice way to check highlights of recent messages. I like it. Right now, I'd probably buy the Microsoft Band or a Garmin running watch instead, as they both have GPSes, natch, but if I was important enough that missing a message could be expensive and didn't want to look like I didn't realize fanny packs are supposed to be worn on your fanny,* this watch would have my attention.
*Btw, folks who don't seem to understand this simple truism -- that fanny packs are to be worn on your fanny -- really bother me. I don't even know if fanny packs are inherently dorky. They're insanely useful when you're hiking and don't want to carry a full pack, or need to get to part of your gear quickly and are wearing a high pack. It's not the accessibility that makes a fanny pack dorky. That, like a calculator watch when you actually need to double check some nontrivial math, is useful. It's the fact that you need to neurotically dip into the pack so often that you allow it to symbolically replace, well, you know, combined with the style faux pas of accentuating your belly, that causes our visceral reason to the dopes that wear fanny packs on their font side. STOP IT, for heaven's sake. ;^)
I donโt think you can remove the push URL; you can only override it to be something other than the pull URL. So I think the closest youโll get is something like this:
"Apple's price of admission for 5K goodness is steep, with prices starting at $2,499 (plus additional fees for custom configurations) but it's worth every penny."
Man, I hate these sorts of pronouncements. $2500 is a lot of money. Good, serviceable (and new) laptops run as little as $250. Lets pretend we're computer shopping, we make forty grand a year, and have kids. Are we really going to part with over five percent of our pretax yearly salary for 3x pixels?
I've heard David Smith and Marco Arment argue for the usefulness of a retina display coupled to a high-powered desktop *for iOS app development*, but I'm pretty sure TechCrunch was assuming a broader audience here.
Worth is a relative term, and one that doesn't belong in even so much as a figurative sense in a trustworthy review. Disappointing.
I really like git-flow (http://nvie.com/posts/a-successful-git-branching-model/). I first used it nearly three years ago, and with a team of, for the first cut of the software, only two people. It actually works quite well. The most important thing about git-flow -- or any git workflow -- is how it partitions changes to your code logically. The primary benefit of these partitions to code changes is, I think, the reduction of production code churn, though this "firewalled churn" provides benefits all the way back to your develop branch, which is thankfully protected from wacky coder changes in each of their (my?!) feature branches.
In a sense, you have three protected sections: 1.) The wild west of feature branches, delineated by the develop/nightly branch, 2.) The staging environment, bordered by, in git-flow, the master-as-production branch, and 3.) The "pristine" production deploy, a sort of "one-dimensional"/breadthless section of code.
That's really all you need a code management flow to do. Protect what we're testing internally from the cruft we develop every day. Provide another protected area where we can test and fix what we think is "done". And lastly, provide a protected area for code we think is ready for deployment.
Today, my current team is looking at using GitLab to host projects, and, while looking around their site, I found a blog entry on "gitlab-flow", which, in turn, appears to be building off of the "github flow" discussed here several years ago:
http://scottchacon.com/2011/08/31/github-flow.html > Both of these issues can be solved easily just by having a much more > simplified process. At GitHub, we do not use git-flow. We use, and > always have used, a much simpler Git workflow.
I'm not sure that I buy that git-flow is that difficult and *requires* a script, but fine. This alternative flow seems interesting in that it's trying (if my first read is accurate) to kill the distinction between 2.) and 3.), collapsing 2.), the hotfix, back down into 1.), wild west development, from my "sections", above. As Chacon says in the github flow blog entry, "there is no difference in the GitHub flow between a hotfix and a very small feature."
Anyhow, this is mostly to remind me to come back and take another look, but my initial reaction is that seems to invite code pollution. There are times that you'll take a dirty hack in production to minimize live code churn to keep things running well for your "real" users while you take your time to fix the underlying issues "for real" in feature branches. That is, github flow seems like it might discourage deliberate bug squashing -- if you need a major rewrite to fix a bug in a forward-looking fashion, take the time. And if you're going to argue that github flow allows you to patch quickly *and* again, deliberately, later, I'm going to argue you want the kludge to live *only* in 2. before you find you're breaking windows in ways that, in retrospect, you wish your coders were disciplined enough to ignore in their day-to-day work. They're not. Worse still, is your company? Or does that hotfix-qua-"very small feature" end up living in production and your codebase forever because it's working well enough?
That said, I'm stuck in a location whose proxy isn't letting me see the images from the blog entry, so I might have to take this all with a grain of salt for now. ;^)
I've been editing a fair bit of Powershell code recently, overly largely in gVIm, then alt-tabbing into a Powershell console (where I type "./scriptToRun.ps1") or to PowerGUI (where I hit [space] for "Ok, reload", and then F5 to run). That's been okay, but I've slowly added Sublime Text 2 back to my workflow, and it seems extensible enough that I could quit the alt-tab, type jive workflow, above.
This is the best quick solution I've found so far, with the caveat that I can't load it up with parameters yet.
To use the new build script, click Tools | Build Systems | PowerShell,
which activates the new PowerShell build system. Then press Ctrl+B to
execute the build.ps1 script.
That'll execute whatever ps1 is active in the editor at the moment through Ctrl-B, with results spit into Sublime's bottom output window. Not an interactive prompt, but not too shabby for the small investment. Kinda cheating (I'm obviously not building anything), but works.
Playing with Powershell, SourceTree (which doesn't diff UTF-16, apparently), PowerGUI, lots of csv files, and Excel means I'm getting encoding crazy. The more I study, though, the happier I am with the decision to swap SqlDbSharp to UTF-8.
Anyhow, to rosetta stone everything to UTF-8, making SourceTree happy, I'm setting encodings with this in VIm.
set fileencoding=utf-8
(Admittedly, I'd rather be using PowerShell ISE than PowerGUI (the latter, at least, defaults to UTF-16, and I needed an "Add-on" to fix it) but PowerShell ISE doesn't seem to notice when I've edited a file with another editor. PowerGUI does, so it's in the rotation for now.)
I'll probably sum all the crazy Excel/csv encoding stuff I've learned in an exciting future post. Spoiler: What a mess.
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity. About Our Author
