Put the knife down and take a green herb, dude.
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.
MarkUpDown is the best Markdown editor for professionals on Windows 10.
It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support.
Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor.
Stop looking. MarkUpDown is the app you're looking for.
|Wednesday, April 11, 2018|
NOTE: I haven't reread/edited this one yet, I'm afraid. Bbl.
In Part 1, we had all the tools we absolutely required to make a single page app (SPA) with VueJS, but the HTML was a mess. Worse, if it got any more complicated and the different "views" shared any UI, we could tell it'd quickly stop being DRY.
The solution to this problem is to employ reusable components. Here's a quick visual from the "Intro to VueJS" video from Vue's home page.
Concentrate mostly on the stuff in the middle... we might want to use that Product Image component in a few different places, for instance. With components, we can define it once, and then reuse all over the place.
Now there are a number of different ways to create components, but, honestly, only a few that really make sense in a practical work environment. The first that we're going to review -- and the one most sites, including Vue's own documentaions start with -- really doesn't make great sense: inline text. But let's do it anyway for kicks. The reason will make more sense later...
Let's take that "cats" markup from Part 1 and componentize it.
Vue's component model is pretty conventional, and awfully familiar if you've used React. Here, there's no real business logic. We just need to get that the
Here the above cats-specific markup as a component. I've got it in a new file marked
And here's how the HTML changes:
That's certainly a lot cleaner, right? If we componentize it all, making similar
A few things to note:
I bet we can do better, right? Let's see if there's a way to keep the HTML in its own file, where we're not worried about newlines or surrounding values in single quotes, and escaping single quotes in the template, and...
Pros and Cons for VueJS Template Types
There's a decent intro to the different ways you can create templates for components in Vue here on medium from Anthony Gore. Let's run through them and list some pros and cons.
The first is what we just did.
2. Template Literals
The second is to use es6's "template literals". This is a new syntax which allows us to define multiline strings using backticks instead of quotes to delimit strings. That's great, and would improve our
That's a big step up, but it's not IE happy at all. For me, at least, that's still an issue. There's also spotty escape sequence support, so it's not really HTML ready. And strangely, they don't have any compatibility right now (20180411) for Safari on iOS. ??
3. X-Templates (script tags)
X-Templates are when you use the trick that you can drop HTML into a
That, of course, can go anywhere you want in your html, or in a script include. This isn't an end of the world, and is actually how we used to do templates in KnockoutJS. The only thing I hate is that it feels a little kludge and that it's harder to get your editor set up to highlight the HTML code as HTML inside of script tags.
The component is very clean, however.
4. Inline templates :^P<######
Inline templates are a horrible idea, and I can't even find a place on Vue's website that claims it's supported. I'm not saying it's not supported. I'm saying it's a horrible idea. Inline templating is when you put the template between the component's tags in your "parent" markup. Here's Gore's example:
OMGWTFBBQ! The whole purpose of components is that you can then reuse them with minimal overhead. Now I get it -- perhaps there are times when you want different markup for each use of the component. Maybe. But if something's ever duplicated, you're stuck cut and pasting markup, and you've lost your DRYness. Yuck.
5. Render Function: Spoilers
I'm going to come back to render functions. *wink wink wink*
6. JSX & 7. Single file components.
The final two involve transpilation. You can use JSX in Vue if you want, just like you're back in React-land. Insert Kerriganian "WHY?!!?!"
Here's why it's not, from vuejs.org:
Tune in next time in Part 3, when we finally get where we're going, using, you guessed, it, render functions, and have a solid architecture that allows templating without transpilation.
posted by ruffin at 4/11/2018 12:37:00 PM
|Sunday, April 08, 2018|
I heard about VueJS a while back on from Shawn Wildermuth guesting on Yet Another Podcast, and figured I'd take a look. The most interesting thing about it was its claim to be a "progressive framework"...
Incremental adoption, you say? As in, I could use its templating without any other libraries? RLY? I mean, Vue bills itself to be a pretty mature lib. Heck, you can go full-bore, Babel and JSX with VueJS if you want to. That marks a sort of max progression. Can we find a similarly minimally progressive stack?
Last year, I spent most of my time working on a system that used React, JSX, and MobX using Babel for transpilation. It wasn't a horrible client-side stack, but I've never wasted so much time on build systems since I was new to ant. We updated and debugged with each new release of anything of those three, and it drove me crazy with what Shawn Wildermuth calls the "ceremony" of coding -- all the magic incantations and rituals you have to go through and maintain before working code comes out.
Using transpilation and riding the bleeding edge instead of writing deployable code means everything you do costs you -- let's say -- an extra 10%, and, in the wrong hands, more. Do you really get that time back with transpilation?
I don't think so. I'm not against transpilation, if it's well managed. But if I can use a library that doesn't require transpilation, but can still give me a good templating system, I'm curious. Just for fun, let's see if VueJS can keep us transpilation-free.
How progressive is VueJS, exactly?
Let's take the minimal VueJS setup as described in their introductory guide, where we assume zero libraries other than Vue are present.
What's below is the minimal Vue setup from their guide, with just enough changed so that we...
Excuse the last. It's an unshakeable addiction.
(That said, you should use JSLint too. ;^D)
And the HTML needed to match is super simple.
And poof! We've got an interactive, VueJS-templated web page.
That's... great. Right?
Vue does observables right
Actually, it is great, kinda.
Vue beats out KnockoutJS easily here. You can very simply put in properties to serve as hooks in your
And then a quick change to our html...
Okay, okay, I haven't looked, but it's almost certainly some getter and setter overhead, which works like magic here. That's why it's important to note that
How not to observe...
NOTE: The follow-on from that is that you can't do this:
But you can pick up the observable train wherever you want...
NOTE: You really shouldn't be updating your
Keep your interests separated.
Moving towards an SPA
There are really only two more things you need to know to get pretty close to making minimalistic single page apps (SPAs) with VueJS: conditionals and loops.
|Thursday, April 05, 2018|
About a week and a half ago, I compared the CPU Mark scores for three inexpensive programmers' laptops. Just for my own benefit, and so I stop looking it up over and over myself, here's what the current "entry level" MacBooks give you:
So compared to my cheap-o Windows laptops, not great, though the "Escape" is probably workable. Here, again, are the Acer Aspire with i3, i5, and what I have now (the i7-7700HQ).
I was wondering if I'd bite on a Mac Pro if one dropped in time for WWDC, since I've been considering a prebuilt tower, but now that we know there's no Mac Pro until 2019, that's not an option either.
It kinda stinks. I've got an excuse to upgrade -- my Windows laptop's battery's age and dated Mac laptop -- but nothing good enough to let me turn that excuse into a true reason to buy. Wish there was a MacBook that was "close enough" to justify the Mac tax.
Which leaves me back at the completely uninspiring but insanely practical & affordable Aspire 15 I mentioned last time or wait and see if we can't get a summer speed bump for the Escape.
posted by ruffin at 4/05/2018 06:30:00 PM
|Tuesday, April 03, 2018|
(Let's take a second to note that that last sentence really does say, "Compete directly with them by signing acts to
I'm waaaay late to the bandcamp party, but I finally mainlined it a bit a few weeks ago. It's not knock-down, drag-out great music, but there's a lot to discover in there. The search interface is exceptionally limiting, for some reason, not allowing complete freedom to pick from what's a pretty nice set of music types, but once you invest some time, you'll pull out a few good bands, seemingly whatever your preference.
And if Spotify could be the music recommendation service I wish Apple Music was, it'd be on to something.
This really is a Reese's Cup commercial. All the parts are out there, and working well. More important than bandcamp is what it represents: indie music has the tools to release high-quality music to the web with hundreds of dollars worth of gear. No longer do they need radio and labels. And there are services that do a good job with music discovery.
Somebody just needs to get that last barrier to entry -- having "all the musics" on the same competent discovery service -- out of the way so that they can move on to Step 3. Profit.
posted by ruffin at 4/03/2018 08:51:00 AM
|Friday, March 30, 2018|
Here's an interesting post on the SourceTree development blog about why they believe their changes to the UI in the last few years are better, and here's another than explains changes to the Windows client specifically.
I get the sentiment of some of the changes, like this one...
... but I don't necessarily get the conclusions. You want to have a coherent design philosophy, like Material Design or Apple's User Interface Guidelines, sure. But I've never noticed tab placement to be a problem in SourceTree. I get that it's not a browser look, but also wonder why we need to standardize on browser behavior. Is overuse of tabs in Windows apps a convention in itself? Probably was. Do newer Windows users balk at that convention and prefer browser conventions? Maybe. I don't know. I didn't see a lot of A/B testing in the SourceTree articles.
What I do know is that I hate the flatness of the newer SourceTree. I also hate how spaced out each line for a checkin is. It's disorienting and not as info rich as the alternating colors version we had previously. I also dislike the icons in the toolbar. Before, the icons were colorful, but not distracting. Now they're as flat and non-descript as a Jony Ives' designed button on iOS 7.
I posted a discussion on their forums, not that I expect to see much in the way of responses.
(I do kinda like that last line in the quote, above.)
But one of the neat things about their own blog posts is that they do seem to care what you think. In that first that I linked to, you could schedule a 1:1 with them to discuss what you thought about design. Let's just go ahead and say that's crazy customer attention. ;^) And they ask for community posts if you have an opinion, so I'm doing my part, I guess.
Makes you wonder, though.
I mean, Linux still hasn't taken over the desktop for vanilla PC users. Why is that? Just apps? I'm betting there's some UI roughness that's also a barrier to entry. Good enough [for functional use] isn't always good enough [to sell (or be eaten?) like hotcakes]. And it's specifically these kinds of changes... less information, buttons being moved to different spots... that are the microactions that make everyone's day to day that much less productive.
posted by ruffin at 3/30/2018 12:32:00 PM
|Wednesday, March 28, 2018|
From martinfowler.com on "Command Query Responsibility Segregation", or CQRS:
I saw this acronym for the first time today in a SO question about Azure Service Fabric, and my HOT TAKE!!11! was, "Who in the world doesn't do this?"
There are two main data transformations that happen in essentially all of my controller code. For GETs, I'm usually flattening a "database is truth" model into a data payload, stripped of stuff like, "LastModifiedBy" (or anything not needed by the client), but also of complex relationships with child objects. That is, when Entity Framework (or any POCO-returning library) gives me, say, an address' stateOrProvince as an entity, I usually flatten that to a
The second is when I return changes to these DTOs. There, the PUT (or PATCH) command often isn't strictly RESTful either [using the database as The Source of Truth]. If I'm returning the ever-proverbial Contact with three Addresses, I don't typically call an Addresses endpoint with a PUT thrice, and then follow up with another PUT to Contacts. I'll send up a DTO that's essentially
There is nothing that, in my experience, causes performance bottlenecks as quickly as folks blindly falling back on performing Commands (actions that "Change the state of a system but do not return a value") via fully hydrated ORM objects. Oh, the humanity.
Treating your PUTs and PATCHes as separate models from your GETs (or at least separate models from those in your database schema) allows you to spare yourself such madness.
posted by ruffin at 3/28/2018 01:51:00 PM
|Sunday, March 25, 2018|
The battery in my Lenovo Y700-14ISK is finally getting to the point that it's holding me back. I might get 60-70 minutes out of it just with casual programming. That's not crazy. It's a gaming laptop, and it's obviously meant to stay plugged in. It also has a pretty phat processor for a laptop (an i7-7700HQ) that made it an attractive programmer's box two years ago.
But two years later, the battery's ready to go.
I've been waiting for a MacBook that was worth buying, and that I dodged buying two years ago with this Lenovo, and I remain hopeful yet again that this will be the year to get back to portable macOSing.
I want portable Windows with battery life, but I don't want to break the bank to buy a ThinkPad, since I'm planning to grab a Mac this buying cycle as my "real" work box.
Acer Inspire: Where has this been?
Then I ran into the Acer Inspire while looking at cheapy laptop comparisons on Amazon. Wow. Look at these two...
That's not bad, but the real kicker is that it seems like this laptop was made for people willing to upgrade. Look inside this thing:
One panel and you've got your SATA drive, RAM, and an m.2 slot accessible. It's like they expected you to swap and/or upgrade this box! Insane!
But once you start adding up RAM and an SSD, well, you're pushing up to around $550. Which almost exactly where the Inspire's next step up lives:
Well, hello. This is getting close to too much to pay for making Windows portable, but isn't the better processor worth an extra $100? Here are some ballparks from cpubenchmark.net -- this first is the i3 in the cheap Inspire, then the i5 in the $600 version, then the one I got in my Lenovo:
Now, for $250 over the cheap Inspire, we get an SSD (though not the one I'd've purchased, and we lose the TB of spinning platter space) and just enough RAM to squeeze by for a while -- and the chance to upgrade to 32! That's nice. Eat 32 gigs, MacBook Pro.
And the processor? Those numbers are close enough to my old i7, I could probably trade it in and not feel it too badly.
It's bigger than I'd like. I don't need the DVD drive. It's still got VGA, which even I finally removed from my desk setup recently. The Inspire is a dinosaur.
But it's an easily upgradeable dinosaur with a good drive & the latest processor for $600. That, my friends, is a proverbially impressive piece of kit.
Do I worry about the cheap keyboard? Yes. Yes and no.
Six hundred simoleons is a bit more than I wanted to spend for the equivalent of a new battery. I always think, "If you could have $X off of your next laptop by not buying now, what could you the afford to get?" And $600 would be nice to put towards a MacBook Pro with its own nice battery.
But any way you slice it, if you want a nice Windows box for some work, and don't mind not having Pro, the Acer Inspire looks like it should be your value baseline.
posted by ruffin at 3/25/2018 12:17:00 PM
All posts can be accessed here:
Just the last year o' posts: