I was very interested in the great-looking Flat UI web UI kit, and had planned on possibly using it in future projects, but doesn't look like that'll be happening now.
The notice was posted online just two hours ago, and the download is no longer available.
...for not presenting users a dialog with a choice of which browser to use (EU).
Roughly six months ago, I began work on a Titanium-based collaborative project, which meant everything I did would have to be in JavaScript. Although the project itself was very exciting, coming from a Lua-heavy background, which I've been using primarily since 2010, I wasn't particularly excited about diving head-first into JavaScript (with which I had experience, but didn't particularly like it very much).
I've always liked Ruby, however, so when I discovered CoffeeScript and learned that it compiled to JavaScript, had a Ruby/Python-inspired syntax, and worked well with Titanium projects—I was pretty happy and couldn't wait to dive in.
So up until about a month ago, I've been using CoffeeScript extensively before ultimately deciding to switch back to JavaScript. I can now say that I actually like JavaScript, but I'll get into that in a future post. For now, I'll focus on my experience with CoffeeScript.
At first, when the project I was working on was new, CoffeeScript seemed to be perfect. It was natural to write in, didn't have a verbose syntax, and seemed to mask all the little quirks and strange things about JavaScript that I hated but have now gotten used to.
I still think CoffeeScript is great, and although it isn't for me anymore, I still have some things I like about it:
There's a few things in the list that I'll miss in JavaScript, but nothing I can't absolutely live without (that shouldn't be possible, considering CoffeeScript is "just JavaScript").
As development continued, source files began to grow, and more-and-more I was having to revisit old files that I hadn't touched in a while (e.g. they were no longer as familiar as they were when I was working heavily on them).
I began to realize that CoffeeScript can sometimes be hard to comprehend, even when code is commented well. This wasn't that big of a deal, because it would never take too long to figure out what was going on, but the initial confusion was unwelcoming.
When looking at somebody else's CoffeeScript code for the first time however, the confusion is worse (more-so than looking at somebody else's code in any language). It turns out that the one-liners, shortcuts, and syntactic sugar that CoffeeScript is known for, while a blessing when writing code, can be a double-edged sword when it comes to reading and comprehending the code later on.
For example, the ommission of the "var" keyword (variables local by default) at times made it difficult to easily determine the scope of some variables, and all the white-space—while I'm sure is welcoming to Python developers—started to make things appear unorganized and chaotic to me. I actually started to miss curly braces.
Another pain point was when it came to debugging. This was never a show-stopper, as it is relatively easy to look at the error number in the JavaScript source and find exactly where it was in the corresponding CoffeeScript file due to the preservation of variable names, but was a tiresome process added onto the already tiresome process of debugging.
Ryan Florence sums up the CoffeeScript debugging workflow well:
- First I have to find where the problem is in the JavaScript since it doesn’t compile line-for-line to my CoffeeScript.
- Then I have to comprehend the JavaScript because it’s not my code.
- After I comprehend the JavaScript I can work on discovering the problem.
- Once I discover the problem I have to find the code in the CoffeeScript to fix it.
- Fix it in the CoffeeScript.
- Compile (usually automated, but still a step)
- Problem fixed, move on, otherwise...
- Wonder if the compile process was successful.
- Go back to the JavaScript to see if it’s what I expect, start over.
Number 2 sounds a little exaggerated to me, because I've never had a problem finding the corresponding CoffeeScript code to an error's line number in the JavaScript source, so there's really very little comprehension of the generated JavaScript code needed. However, it is an inconvenience, especially when you consider the fact that you probably already have way too many source files open at any given time.
Strange JavaScript output is something I've seen CoffeeScript produce, mainly in conjunction to generated for-loops, and it's actually even caused errors a few times (which is a major drawback, in my opinion). I'm sure there's some perfectly sound technical explanation for this, but that doesn't make it any less scary:
for (i = _i = 0, _ref20 = collection.length; 0 <= _ref20 ? _i < _ref20 : _i > _ref20; i = 0 <= _ref20 ? ++_i : --_i) {
// code here
}
Just imagine when that's where your error is at and after checking the CoffeeScript code, you see that it should work. Whenever it happened to me, I would end up having to re-work my logic so that the generated JavaScript would be different in order to get around the error, so running into that a few times really left a bad taste in my mouth.
It may sound like I'm bashing CoffeeScript, but that is not my intention. I still like the language and think the developers have done a great job overall. I highly recommend giving CoffeeScript a shot for yourself, if even just for educational purposes, and so you can make your own decision about it.
As a side benefit, using CoffeeScript and studying the output is actually a great way to understand JavaScript if—like me—you don't have an extensive JavaScript background and would prefer to be eased into it with a Ruby/Python-like approach.
For me personally, at least for now, I don't think I'll be using CoffeeScript anymore in the foreseeable future. It definitely has its pros, and I can see how others might feel differently, but this was my experience after an extensive run with the language. I learned a lot, and most importantly, was able to make a more informed decision about whether I should go with CoffeeScript or just plain old JavaScript.
UPDATE: discuss this post on Hacker News.
Farmers in England build their own broadband because they can't get an ISP to do it. Hat's off to these guys—that's awesome.
Great advice for anyone who does any amount of work at home. I especially agree with numbers 5, 8, 9, and 10.
In 2010, he was developing on a production server and had an accident:
...one lazy Tuesday afternoon found me drowsy, cursor hovering over the USERS table icon, to then bring up its menu and click 'clear'.
This is the part that made me cringe:
The game had tens of thousands of paying customers. Users who'd paid to buy special items within the game to enhance their character stats. All of these character stats were stored in the USERS table, now void.
Exactly why you should never develop on a production server, or production anything for that matter. I can't believe that was even able to happen in a company earning "millions in revenue".
"And then during that day — it’s usually a day-long event — emails are fired all over the place with views whether this person should be hired or not until some consensus is reached where there’s effectively no one is vetoing the hire of that particular person."
Very unique to say the least. Valve truly believes making great products are the result of great teamwork, and they live by it. Seems to be working out great for them too.
... why would you want to re-implement something half-assed from scratch when you can just find someone who’s done it before?
This resonates well with what I liked about developing in node.js when I created oberon. When you need additional functionality for a piece of your app, someone has most-likely already done it better than you would be able to do quickly. And they probably released it under a flexible open source license, thus allowing you to focus more on what you're really trying to accomplish.
App.net has reduced their price from $50/year to $36/year, and is now offering invite-only free accounts. Sounds good right? I'm not so sure...
First and foremost, I'm totally on board with what the App.net team is striving for, and I especially like how their service is ad-free, respects user privacy, is all about developers, and has users as customers (as opposed to users as the product for advertisers).
However, I think their pricing structure is a little self-defeating. They've made an attempt to lower the barrier to entry by reducing the price, which to me says they know that in order for their service to succeed, they need more growth. But it doesn't seem like it's enough to get the really explosive growth they need to gain traction outside of the tech community.
For developers, App.net's main appeal is that it serves as a generic social platform for developers to utilize as a back-end for creating different kinds of social apps, but doesn't it put developers in difficult position to also have to convince users to join App.net? I think it's difficult enough for developers to convince users to pay for their app without having to also sell an additional required premium service—and don't even think about offering your own premium subscription-like features to your App.net-based app right now.
And unless developers emphasize to their users the need for a—most-likely premium—App.net account, they're going to have a lot of angry people on their hands who made a purchas only to realize—after the fact—that they also need to purchase a subscription to even use it (unless they happen to be friends with someone on App.net, which would be not be a good thing for developers to assume of most users).
Marco Arment sums up the root of the problem for developers pretty nicely:
If I want to build an app with a social network backing it, I should use Twitter or Facebook. Developers need to support the biggest social networks because their role is to spread our apps. Building an app exclusively for App.net would work against us.
So how can App.net accelerate growth and not hinder developers at the same time? Simple: make joining the service free for users (no invite required), with the same limits, keeping all the premium options available. And of course, continue to charge developers for API access, while occasionally adding features that appeal to a wide range of app developers (possibly adding more developer tiers for apps with really high usage).
Why could this work?
Take Appcelerator for example, a company known for its mobile app SDK, Titanium, is actually doing something similar with their cloud services (ACS) offering. They have a few tiers of API access to several "cloud" features, many of which are social-centric and similar to what App.net offers. Developers don't even have to use the Titanium SDK to take advantage of ACS. They simply sign-up and begin making apps using ACS as a back-end for their apps right away. Users don't have to pay anything more than what developers ask them to.
Where App.net would be different than Appcelerator in this regard is that they could offer a standard, vanilla, Twitter-like social network on their website for users (as they are doing now, but open up the free tier to everyone). They would then continue to develop their web-based app over time whilst eating their own dog food by using the same APIs that are available to premium developers. They would still make money from premium users (not unlike GitHub's pay structure).
Developers, on the other hand, could take advantage of App.net's userbase (similar to how developers take advantage of Twitter and Facebook's userbase) without having to sell their users on a separate premium subscription (which would be completely optional and up to the user), and thus build truly revolutionary apps using a wide range of social and cloud-centric APIs for a fee. Developers could make apps and build up App.net's userbase, usage, and contribute significantly to its growth. I think it's a safe bet to say that most people using today's App.net clients were already App.net members. But it could go both ways, and it should.
For instance, Social-Photo-App-X could sell their product, and instead of users joining their homegrown backend service, users would simply either sign up or log into their existing App.net account. Today, users would pay for the app and then be presented with a login screen, or an App.net paywall if they've never heard of App.net (the most-likely scenario)—ouch.
What I recommend is almost what App.net is already doing, with the exception of allowing anyone to join for free. By making a completely free user tier with limits, no invite required, App.net could grow faster while continuing to make money from premium users and developers. They could still be ad-free, respect user privacy, and not have to sell their souls to advertising agencies to make money. Everyone wins.
Anyway, that's my two cents. I really want to see App.net succeed in the long run, but in my opinion, their current structure makes things too expensive for a huge amount of users to join, and that makes things too difficult for many developers to really take their platform seriously. More users. More developers. Two things that App.net really needs.
Besides, wouldn't a service like that fit their generalized name, "App.net", a little better than it does now?
After a bit of a hiatus, my web presence is back online, and at a brand new address: jonbee.be. I actually have a difficult time thinking of what to write for the first post of any blog I start, so I think it'll be safe to start off with how I created the website, and what I use to maintain it—that should be interesting for anyone who might be "consuming" anything I post here in the near future.
This time around, I decided to homegrow my own simple, static blogging engine (aka "baked" weblog) completely from scratch. I also created the—admittedly very simple—HTML/CSS design, with the color scheme loosely based the Tomorrow Night code syntax highlighting theme by Chris Kempson.
UPDATE 27 Feb 2013: This website's design may (and most-likely will) change in the future, so for those browsing the archives in the future, here's a screenshot of what I'm describing above.
I've written a static blogging engine before, as well as a full-fledged developer documentation CMS (both in Lua), but I found that Lua—while very capable of handling this type of thing—isn't something I'd prefer to write a static blog generator in anymore.
Given the amount of JavaScript I've had to get into this year, and despite knowing full well that Python, Ruby, and PHP are usually what these things are created in these days, I decided to write oberon as a command-line utility using JavaScript and node.js. Can you tell I got tired of all the cooking and baking references when it came to static blog generator names?
I plan on getting into node a little more in future posts, but I will say that the experience has been very pleasant. With the huge developer community and Node Packaged Modules (npm), it's relatively easy to make just about anything you want (within the scope of node's capabilities, of course).
When I want to start a new entry, I fire up a new terminal window and type:
$ oberon newpost
...and my default editor for Markdown file opens up the text file, which is a simple template with a short YAML header for things like the title and post date/time. When I'm done writing, or want to see my progress, I rename the file to something like post-title.markdown and type the following into the terminal:
$ oberon generate -p
That generates a local preview version of the site, and automatically opens it in my default browser. When I'm happy with everything, I type in one more command:
$ oberon generate
After that, I simply commit/push my changes in git and that's really all there is to publishing posts on my blog. Simple, frictionless writing—and that's exactly what I need to maintain this website.
I have no need for all the bells and whistles of platforms like Wordpress, and I also wanted to learn more about node.js so this seemed like a good project for learning my way around it. An additional benefit is that if my blog doesn't do something I want, I can implement it whenever I want.
Once I add a few more important features, I hope to one day make the whole system a little more generic, write up some documentation, and then release it out to the public. I think a lot of people would be happy to use a static publishing tool such as this, but without the complexity of something like Jekyll.
I'm not making any promises though, as I may never get around to making this generic enough for public consumption. If enough people show interest, that may be just the kick I need to do it sooner. But as it stands, it is highly usable for my own needs, so I'm happy either way.
Copyright © 2013, Jonathan Beebe