Self-Assessment

View fullsize

​Don't worry, you're not most people.

Meteor: A Great Application Platform

I'm not really a programmer, but I play one on the internet.

As I delve deeper into learning Meteor (and in parallel, traversing a couple online JavaScript tutorials) I find that programming is something I understand a little bit better than I used to. I have few years experience with front-end technologies like HTML and CSS, but dealing with databases and "smart" stuff just hasn't been something that "clicked" with me. Since Meteor uses JavaScript all the way around (runs on Node.js server side) it's something that I'm picking up relatively quickly. But the ability to use JavaScript throughout isn't what's most impressive about Meteor. The most audacious is their mission:

Today, there's a chance to create this new way — to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database.

(Did you read the whole thing? In the last paragraph, they use the word audacious too. It's warranted.)

In my humble opinion the Meteor team is well on their way to accomplishing their mission.

Meteor is built on the idea of "Smart Packages." It's not a complete replacement for the wonderfully useful frameworks out there such as jQuery, Handlebars, or Bootstrap. Instead, like my friend James says, "Meteor is kinda like the glue" that binds those useful resources together. It then intelligently handles data transfer between the user facing site and the servers. Once you get the hang of a few snippets of the magic Meteor brings to the table, you are free to use a framework you're already used to.  (Note: I said "data" transfer, not "entire rendered HTML transfer.") 

Based on nosing around their Google group and their documentation, it appears that part of the Meteor team's plan is to offer a full blown end-to-end development universe including a PaaS for cloud apps. I saw in at least one place the service was referred to as "Galaxy" (fitting, no?). That said, you're not locked in to using their service. But being able to simply type: "meteor deploy myapp.example.com" without needing to first configure any servers in order to test your latest idea live almost makes it not a choice. It's just so easy! (Let's see if I change my tune after they figure out and announce pricing).

Overall, I'm excited about Meteor and optimistic about them achieving their audacious goals. I really appreciate the direction the Meteor team is going and wish them well.

So, what do you think? Is Meteor a big deal? ​

Reasons to Blog

In order to clarify for myself why I'm doing this, I thought I'd write down a few selfish reasons I've started this blog:​

1. I'd like to become a stronger writer and storyteller
2. It's a hobby that can be done from just about anywhere
3. It's nice to have a site to send people who want to learn more about me
4. It's nice to have a log of what I've been thinking about
5. I want to express and interact with interesting ideas

Is there anything you've started (or stopped) doing recently?​ Is there anything you want to start?

Reimagining the Publishing Industry's Project Development

Version control is important with any sufficiently complicate project. Once I started learning Git, I slowly realized how powerful it was. I had the "aha" moment for why repository hosts like GitHub and Bitbucket are so useful for software developers. The ability to clone, branch, fork, and otherwise work with complex projects is invaluable. Thanks Linus!

​Not too long ago, I watched a TED talk where Clay Shirky discussed using version control for lawmaking and government. I really liked that concept.​ He talks about version control around 6 minutes into the video.

So I started thinking... what other areas could benefit from granular version control?​

The most obvious one that came to mind (since I'm married to an author) was the publishing industry.

​Imagine if publishers had a complete log of project changes, the ability to branch, rewind, fast-forward, and have departments, authors, agents submit pull requests for all project changes - everything from the initial proposal received from the author to all edits and variations of the manuscript. And why stop at just manuscript changes? Why not all changes associated with the project, across multiple departments including cover variations, type setting, and advertising creative. Sound too complicated? Consider the complexity of enormous projects like the Linux Kernel, spread across the world with thousands of contributors. It's kept manageable and efficient by version control.

​If you work for a publishing company, you have a vested interest in "staying relevant." Your survival is at stake. Want a competitive edge? Want to stay nimble? In the age of social media, you'll need to continue to offer new authors more than industry connections. You'll need to be more efficient and more effective at project development than what authors could reasonably accomplish without you. I'd suggest that a great place to start would be to fundamentally shift how you view the importance of the littlest things; the incremental changes to each of your projects.

Why not incorporate the technologies that provide efficiency to some of the largest and most complex content publishing projects in existence: software applications? These are projects that can't afford a single typo without major consequences.

Imagine increasing the quality of communication between departments, agents, and authors while simultaneously speeding up the entire publishing chain, lowering the rate of errors and logging every important change ever made to any part of the project. That's the kind of shift in process we're talking about here.

If you're in publishing and want to learn more about the areas in software development I think could help your industry, here's a list of things to start considering:​

• Git version control
• Agile software development techniques
• Centralized data storage (or cloud storage options)​
• Hire quality Interdepartmental ​geeks that can translate tech terms

So what do you think? Would version control be good for publishing?​

4 Practical Steps for Building an Online Audience

[Trigger Warning: Web 2.0 Buzzword rage]​

I'm convinced there's no magic to building an online audience. Success "on the internet," if you define success as gathering an audience or some measure of influence, relies on the same qualities that under-gird success in other interactive content driven contexts. Good people skills and valuable content are top of the heap. Those resources will help you build a reputation, which is what you need to "break through" or "be noticed."

Much has been written about the technical side of things. There are already plenty marketing buzzwords like SEO, social media, going viral etc. that quickly and vaguely translate very technical ideas into key-phrases suitable for use in boardrooms filled with non-technical executives. And while your "marketing strategies" may be good for getting more traffic, they should always be considered secondary to your content and personality which is fundamental to how you build your reputation and by extension your audience. In that vein, here are four steps I think are important to building an audience.

​1) Don't be anonymous

When you're first starting out, the only people who will read what you write are your friends and family. They already know who you are, don't pretend to be someone you're not. Make sure to have your name somewhere easily accessible on your website. As your friends start sharing your content, your new audience has a name to put with it. This allows your growing audience to categorize you in their mind as "friend of a friend" instead of "that website" and they'll be able to more easily find and follow you on social media sites, twitter, Google+ etc. if they like what you have to say.

2) You're not smarter than your audience

Everyone thinks they're the smartest person in the room. I challenge you to be different. There's a good chance the people you're writing for are smarter than you. Don't fall into the trap of thinking you're writing for a giant mass of zombies that you need to trick into following you. Write what you think, write what you know, consider that everything you write will be read by someone who knows more than you do. Don't try to prove you're an expert, just offer what you have and let others decide if it's valuable to them. To some you'll be a guru, to others you won't.

3) ​Don't expect instant results

The internet speeds up information sharing, but this gives an illusion that everything is "instant" online. The reality is that, while a web presence can help you build an audience, it's not instant. Building a substantial audience can easily take years. ​Also, the "tricks" to building an audience are actually quite boring. Create valuable content, make sure it's accessible, repeat. If you try to take shortcuts, you'll end up just spinning your wheels and paying SEO Web 2.0 Acme Audience Builder Inc. a lot of money for traffic that does you no good.

4) Reputation grows an audience

Reputation is the ground on which you spread your seeds of traffic to grow an audience. Even if you got an extra 1,000 visits to your site today, unless you've built a strong library of content and useful resources, you'd be back to normal stats in a day or so. You need a reputation, which comes from a history of sharing little pieces of yourself in this public space we call the internet. It's not just about traffic. Earning a reputation takes time.

So, to summarize: There's no magic, be prepared to get little to no traffic for at least a year, long term audience growth depends more on your reputation and your content than your technical ability.​ If this depresses you, revisit why you want to build an online audience in the first place. Decide if it's worth it. If you decide it is, then what are you waiting for? Do it.

What would you add to this list?​