Miles Matthias

This week Facebook made some news. I’m not talking about the ridiculous IPO, I’m talking about the ridiculous iPhone app “Camera”. I didn’t buy any Facebook stock because I can’t stand their company and how they do things. “Camera” is a fine example of their sleaziness.

First off, they just paid $1 billion for Instagram and instead of putting effort into evolving Instagram itself into what they want it to be, they release a knock-off version of Instagram solely for Facebook. Why would they do that? Well, maybe they didn’t want to be accused of copyright infringement. Doubtful. They probably did it to have the smart people at Instagram help them design and write “Camera” and even let them borrow parts of their code. Fine, but you have enough smart engineers at Facebook, and they could have done it all by themselves. Surely the acquisition of Facebook is part of a larger, long term strategy, but releasing a crappy version of Instagram right after paying a billion dollars to own Instagram seems like a really dumb thing to do.

That’s not what this post is even really about; I just needed to get that out. What really bothers me about the Camera app is that Facebook will sink to trickery to snatch people’s pictures for Facebook’s revenue streams. For those of you without an iPhone, there is already an app called “Camera” on the iPhone. It’s written by Apple and is included with every iOS, camera enabled device. It does exactly what it says - gives users the ability to take pictures and video. That’s it.

Facebook decided to name their app “Camera” in the hopes that some users would confuse the two and instead of using Apple’s Camera app, they would use Facebook’s version. They hope that users will unexpectedly take pictures with Facebook’s Camera app and instead of just saving the picture locally to the user’s device or on the cloud with Apple iCloud for storing and sharing later, the picture will automatically get uploaded to Facebook so they can have better usage statistics, so they can please their newly appointed wall street bosses.

They took it a step further to design an icon that looks exactly like the built-in Apple Camera app.

Can’t you see your parents or grandparents mistaking this app for the Apple Camera app and never noticing? (Unaffiliated picture by Matt Galligan)

This is why I hate Facebook as a company: Facebook doesn’t care about their users. Facebook only cares about their revenue stream. They will violate your privacy, they will deceive you, they will give you the worst website and mobile app service imaginable, because they don’t care about you. They generate money from selling advertising space and stocks. That’s who their customers are and that’s who they please.

And yet, people still use it every day. I still use it. The only reason I use it is because all of my family is on it and even with Facebook’s terrible app experience, it’s much easier to share a picture on Facebook to show everyone in my family than e-mailing everyone individually. Facebook knows this, and that’s why they don’t care.

I also have no idea why Apple would allow this. It’s so blatant and dirty, and yet with Apple’s extensive App Store restrictions, this got through. That’s a separate post for some day I guess.

This is a confusing time to be a young developer.

HTML5 vs Native. It’s everywhere. It’s an all out war. People are picking sides and fighting passionately about why they’re right. The battle may never end, and if it does, it probably won’t be in my lifetime. I’m a young developer and I want to get great at making great products. But I would hate to get to be an amazing web developer only to find out years later that native apps are really the way to go. And vice-versa.

I’m lucky I work at InspiringApps, a Boulder team that loves making all apps, web and native. I’m working on a cool HTML5 app that uses WebSQL to provide an offline experience (I’m learning a ton, it’s awesome!), but next month I might be coding an iPad app in Objective-C. Who knows? I love that. I get to soak up knowledge and experience from all sorts of technologies in the making of great products.

Maybe in the grand scheme of things, it’s not important which language or architecture you’re implementing something in. Maybe if you want to get great at something, you should get great at design. Design something really, really well, and then figure out the syntax to make it happen later.

But when I say design, I don’t just mean UI/UX design. Designing the implementation of a product is crucial as well because a good road map will cut down on the time and issues involved in actually building the product. But to design a good road map you need to know all of the little bumps in the road that you only learn by traveling it a thousand times!

Maybe there aren’t that many bumps in the roads. Maybe doing something once or twice is enough to design a product architecture wisely. Then you would still be an effective product designer without needing to know every little intricacy of a language/platform. Maybe there will always be little weird problems you have to hack out, regardless of how long you’ve spent becoming an expert at a certain language or platform.

It’s exhausting figuring this all out.

If you’re an experienced (a.k.a elderly) developer, what’s been your experience? What one thing are you great at? Leave a comment below!

A few weeks ago a group unveiled a new application platform that blurs the lines between server and client, called Meteor. With the main goal of helping developers write web applications “that are ready for 2012, not 1996”, Meteor provides automatic data synchronization across multiple clients, automatic hot code pushes, and a “Smart Package” system that allows for easy feature inclusion.

The idea of writing web applications in one, consistent manner is an exciting one considering all of the different components you need to manage when building and operating a website. In addition to the numerous advantages it provides seasoned web developers, I can definitely see Meteor being a reason for more people to start learning web development since it significantly simplifies everything.

After getting over the intimidation of trying to learn a platform that four guys from MIT are writing, I decided to try to play around with Meteor and try to get a feel for it. First, I forked their repo on github and downloaded it to my machine.

I travel quite a bit, so I wanted to figure out how I could read their docs offline. It took me a while to notice that their docs folder in the repo is actually a meteor application itself. So all I had to do to read the docs locally was to launch it:

cd docs/
meteor

A few days later I added a note to the README in my forked repo and submitted a pull request to get this changed in the main repo. It was my first pull request on github ever, so I was excited, even if the change was minimal. Hopefully I helped someone else read the docs offline faster.

Then I started thinking about a very small web page to build with Meteor as a learning experience. I saw that they had some examples, so I decided to learn by modifying one into my small example. Their simplest example is called “leader board” and shows a list of scientists each with a corresponding score and a button that the user can click on to update a selected scientist’s score. Deploying the example to a server (Meteor set up a bunch of free servers to test on, how cool is that?!) will allow any client connected to the example to see the score changes in real time and sync their score increments to every other connected client.

The small task I wanted to do was to modify the leader board example to be a launch page where a user could input their email address to sign up for some sort of beta launch or private invite, and the number of people that have entered their email address would be displayed and synced to every connected client in real time.

It took me about 30 minutes to get the hang of everything Meteor and to build a working version:

The way it’s currently written syncs all emails given to every client connected however. That’s probably not desirable. So I started wondering how I could tell one collection to auto publish but not another. In addition to thinking about my own concerns about security, I was led to an article on the Britto Blog where I saw I can remove the auto publish package from my app and then publish individual collections manually, which would mean I would need to then subscribe to individual collections manually as well.

I’d like to actually implement that and publish it on my github account soon, in addition to think more about Meteor’s security and post any thoughts.