In which I play around with Vico

For many the holy grail of text editors is Textmate. In a very short time it became an indispensable tool for many, many programmers and sysadmins.

Then it stagnated horribly, it gets updated perhaps once per year (and then only to keep it running on the new OS release), and god forbid you find a bug: it will probably never be fixed.

(As I write this there is an alpha promised by Xmas. Many are understandably cynical about this.)

A bunch of projects started up to fill the vacuum created by TM2′s vaporware status. Without sounding too negative on what was an incredible amount of work, they’ve managed to re-implement much of TM1 in the time it took to get TM2 to alpha status. That said making your app compatible with the huge TM1 ecosystem (and what may be the TM2 ecosystem) is an obvious good design call.

Anyway, the two I had immediate access to are Vico and Sublime Text 2. More on Sublime Text 2 later.

To reduce it to the simplest description, Vico is a vi implementation in Cocoa (or at any rate, Mac-native) that is mostly TM-compatible (themes and bundles).

(Also note: I’m sort of unfairly conflating vi and vim here. Pedants, don’t freak out. Hopefully you’ll get what I mean.)

Whether or not you consider vi’s modal editing a plus or minus is not really even worth debating. If you don’t like modal editing, don’t bother to even try any modal editor.

Vico supports a pretty finite subset of vi commands, but enough that you’ll preserve basic muscle-memory when editing. As near as I can tell, commands aren’t as “composable” as a real vi, but that’s where the bundles take over.

Vico supports a subset of TM bundles, so you can probably drop in some functionality that would normally be done with vim macros or scripts.

You can also “drive” Vico’s functionality with built-in scripting using the Nu language. Nu is the (perhaps unholy?) fusion of LISP and Objective-C/Cocoa.  And example of using Nu scripting to perform an editor task (automatically hard-wrapping text in this case) is on the Vico blog.

Is that any better than Vim script, or ELisp? I dunno. Vico seems like too much mashed together. It’s in a weird place: if you’re determined to retain modal editing, why not just use MacVim? Well, MacVim is … not so much ugly as plain. So, assuming the creator can keep up with the state of the art enough to keep the users happy, it’s a nice way to appeal to modal editor junkies who somehow don’t fancy MacVim.

But what of the people coming from TM? Isn’t modal editing a huge change, even if it lets them keep some of their workflow? OK, you’re addicted to some set of TM features, but hopping into the world of modal editing seems like as big a jump as switching to some other editor (BBEdit, etc).

Anyway, Vico is an interesting project and I sincerely hope it stays around for a long time: I’m hugely in favor of taking “venerable” Unix concepts and wrapping them in modern clothes.

 

How to enable the FTP server (ftpd) in Lion: PLEASE DON’T

TUAW has a HOWTO on enabling the FTP server in Mac OS X Lion.

Please don’t.

FTP is insecure. Your password can be the single-most unbreakable string in the universe, but it doesn’t matter: it’s sent out over plain text. Moreover, anyone who’s been in the sysadmin game for more than 12 minutes has seen just about every FTP server get cornholed, literally cornholed, multiple times by securtity flaws.

The best thing the “technology community” can do is to actively discourage its use.

FTP over SSL is a better interim solution, if keeping “pure” the FTP protocol is required.

And enough about the damn “extra overhead” of SSH or SSL. We’re talking about a few bytes here, esp. when you’re on a LAN.

The sooner FTP dies, the closer we are to a world of endpoint secure protocols.

TextMate to BBEdit switcher’s guide: BBEdit has command-t now! (well, sorta)

For the full details, see here:  https://groups.google.com/d/topic/bbedit/J5YUlmHsVvM/discussion

Now, this feature is wonderful if you’re a long-time BBEdit user. It’s pretty extra awesome if like me you can only run PeepOpen on some of your Macs. And, for switchers looking for a native way to replicate their beloved cmd-t, it’s not bad.

That said I can totally understand why switchers would say “Not the same, not what I want/need”. My dream was to see them re-use the same dialog as the “Insert Clipping” window, which is just like (or damn near, in any event) TextMate’s window. PeepOpen includes extra functionality like showing SCM status.

Still, you can bind it to cmd-t and it’ll work close enough that your muscle memory might not get too confused. And be sure to check out the even more recent betas; they’ve been doing some big performance improvements (one of the reasons I have always kept BBEdit in my Applications folder, even when I’m trying out another editor or using an IDE for stuff like Java).

Fixing PHP: Perhaps more contributors is the solution

I had an alternate take on a point in this excellent post.

However, falling back on cavalier attitudes like the ones behind the statement “nothing is stopping you from contributing” is both insulting and counter-productive.

The alternate view is that lots and lots of things stop people from contributing to PHP: from a possibly daunting learning curve to lack of experience with a language engine to lack of C experience to the occasionally frosty nature of Internals.

It’s a pie-in-the-sky idea that will never happen, but if more of PHP was written in PHP, more people could contribute meaningfully; perhaps it would be easier to write tests, and fix problems.

Of course that potentially (if not probably) means re-writing the Zend Engine (think PyPy or Rubinius) and that’s just not going to happen, probably ever (for some unknown value of ‘ever’).

 

Burned down, fell over, THEN sank into the swamp

So, a very long time ago, I had to write a very small cart app as an adjunct/add-on to a customer’s full store. The idea was, they’re going to sell a very select subset of products and they don’t want to do a huge install and pay for lots of new hardware and software. Make it run – and well – on the couple of spare boxes.

I did it in Rails but the performance was awful. So, as a side-project while I was working on optimizations, I re-built it from off-the-shelf PHP parts, and it was blazing fast. I used the bare minimum of parts – a simple router, a simple ORM, and my own dispatch/controller (that was conceptually stolen from Rails).

Like I said, it was a bare minimum app. It didn’t do a TON of things. As customers are want to do, they came back and asked, “Where are all the other things? The things it needs to do?”

“It doesn’t do those things”, I replied. “It says right here in the contract, ‘we aren’t going to do those things’, those things are to come later.”

Well, they were going to think about it, since we were going to charge money for those things. I started a little “plugin” thing to bide my time while they thought about it.

They thought about it and decided they didn’t want to pay for those things. Project cancelled.

Time passed and I had reason to pull out the codebase again. “Hey”, I said, “let’s implement some of those things to make it more attractive”. Before I could get an answer, this project was cancelled.

More time passed, and I began a huge “refactoring” of our existing product. It started off by folding in some bits from the tiny app, but eventually it became clear it needed to use a real, unified “stack” since getting all these disparate pieces together was actually more fragile than the ball-of-mud approach. So I abandoned it, yet again, and used the functionality provided by the framework we chose.

I was looking for some other file when I came across it in a directory called “misc” in a directory called “prototypes and saved things” in my project folder. So I put it up on Github.

It’s incredibly boring: it’s just a little PHP thing to let you hook into a “controller” (say, an MVC type thing) and call a set of defined thingees in an order you want. It’s a really, really dumb pre-and-post-dispatch type deal.

The story is far more interesting than the code.

Safari 5.1 and “random reload”

So by now, you probably have an iPad. Right? There’s like, eleventy-billion of them sold so far, or something.

At some point you’ve probably been browsing around on the web, and then decided to play some Angry Birds, then back to web browsing. You open up Safari, and there’s the page you were reading; or at least there will be in a moment, because it just reloaded. Some times you can have a couple of “tabs” open, and visiting each in turn forces a page reload.

It’s incredibly annoying, but it makes sense: there’s precious little memory – real and virtual – and so some algorithm decides if a page should be kept in cache or flushed.

Well, Apple decided this was SO. INCREDIBLY. FUCKING. AWESOME. they decided to include it in Safari 5.1 for OS X. If I was using Lion to type this, I’d include the little shit icon/emoji.

Presumably this is some way to stop shitty JavaScripts from leaking and beachballing the entire OS. Or maybe they just thought it “just worked”.

Suffice it to say, many people aren’t happy. It’s finally gotten to me, having had a page reload in front of me while I was using it, with no other tabs open. That’s right: Safari had exactly 1 window with additional tabs and I got a page reload whilst flipping between my editor and the page o’ documentation.

Scuttlebutt is that disabling Java fixes it. I don’t know; in any event I have mission-critical services for work that require both Flash and Java, so I guess I am sort of screwed.

This brings up my eternal gripes with Firefox and Chrome: they annoy me to NO. END. As an example, I can’t get Chrome to set the icon in the Downloads folder, so whatever I last downloaded – disk image, picture, document, whatever – is the default white rectangle in my Dock. Always. That sort of makes the Downloads folder pointless (as a Dock item, anyway, in my humble but correct opinion). I tend to use it rather a lot, so having it not work is a giant poke in the eye.

There’s about 20 other things about Chrome I can’t seem to find an extension to correct. I honestly don’t see how people use it, on Mac OS X anyway, because it’s just covered in sharp edges. Is there anything more popular and yet, more warty and unpleasant?

Oh, right. Firefox. Don’t get me started: every time I open it, some extension is disabled for some reason or another. Now they’ve unveiled a plan to make that worse which is pretty great. I’ve only just figured out how to convince Firefox to stop grabbing the default client preference on my Mac – years after I’d decided Transmit was the best ever.

Anyway.

The point of this rant is that I’m pretty unhappy now with every browser out there. If I can’t find the switch for Safari’s “use the ungodly amounts of RAM I can buy cheaply” setting, what the hell do I do?

So we had an earthquake…

7kDXs

Some BBEdit goings on

Some cool stuff in BBEdit-land:

  • BLATANT SELF-PROMOTION: my own BBPackage (AFAIK the only on on the internets!) for better Zend Framework hacking. Now includes completion data and other stuff.
  • Clippings clippings! No longer must you look at page 259 of the manual! Also on Github.

I’ve got a few applescripts in progress, like one to emulate the Surround.vim plugin. I have a few big projects to wrap up at work, hopefully I can find the time to finish them.

Let’s build an ecommerce web app, Part Two: 3 letters, 3 more, and then 3 more still

So! You’ve made it this far. What do you need to start thinking about? Probably what kind of bitchin’ language and framework you’re going to use, right?

No.

The first thing you need to think about is SSL.

So here’s the deal: totally really smart people often make the mistake of thinking about SSL. They get hyped up to use some big “cloud” thing and forget the golden rule of SSL:

No virtual hosting.

Hell you might even be saying right now, “Crap you’re right, I forgot about that!”.

It might not matter to you, though. In our experience, customers demand that the checkout process occur on their domain and not at storename.somecompany.com. Your mileage will vary. Bear in mind, though, that the two paradigms – hosted checkout versus integrated – will strongly affect all your future technical decisions (which is why we talk about it first).

There’s hope, though: SNI. The short answer to “what is SNI” is “SSL virtual hosts”.

The downside is everyone’s absolute favorite piece of technology, Internet Explorer 6, which doesn’t support SNI. Because IE6 ruled the roost for so long (hell we’re still waiting for it to go away), adoption of SNI has been … slow.

You could decide “screw IE6″ and start using SNI today; check the wiki article for all the stuff that does support it, it’s pretty comprehensive. You can make that call today.

In our experience, approximately 100% of the web-browsing public uses IE6. That’s not a joke: almost 100% of our customers are using IE6 on XP right now, and close to 100% of their customers are using IE6. Your mileage will almost certainly vary.

It’s the first big design decision in your app: do we support IE6 at all? Doing so will dictate a lot about front-end development (Javascript frameworks), and as I said, whether or not you want to deep-drive into SNI or stick with the tried-and-true SSL configuration (1 IP per host). Do you want to “funnel” your customers into a unified checkout or have virtual hosting with the checkout process on each host?

 

Let’s build an ecommerce web app, Part One: You might be insane

SO! You’ve decided to enter the fray and start your own internet company: you’re going to develop and host online stores, targeting all sorts of businesses.

Frankly, you’re insane: people will throw dump-trucks of money at you if you try to “change the world” by opening up a new social network for chinchillas, or a Facebook app that simulates sitting in traffic. Trying to enable small merchants to sell stuff online isn’t really all that world-shattering. No one really cares.

After all, they can just host their store at a big existing commercial provider, like Yahoo! Stores; or they can roll their own store with Paypal; or they can get some commodity hosting and install a free cart app.

Well, yes. You can do all those things. And sometimes, they’re good ideas. Other times, they’re not. How do you know? You don’t. Each of these solutions offers a certain level of pain: for example, installing a free cart app on commodity hosting means you are now a designer, sysadmin, programmer, and IT manager. The hoster probably has N other customers running who-knows how many other random free cart apps; if your store is down their level of commitment may end at “well the web server is up and running, so it’s your problem”.

That’s the essence of your business case: the “easiest” options are in fact complex and fraught with peril. You’re an expert in the tools, the tech, and the business know-how. Host with us, we’re awesome!

I don’t want to talk about business; I don’t know it. I wanted to instead go with what I know, technology. Let’s assume you’ve got a co-founder with great hair and a flawless smile to handle all the business stuff, and you’re in charge of the technology. I want to talk about bytes, not bucks.

On our next episode: 3 little letters, then 3 more, and how they’ll make your life miserable.