Google

The Chromebook: Prepping For Dev Work.

Chromebook Test

Chromebook Test (Photo credit: slgckgc)

With some problems with my main work machine last week I decided to get a cheap machine as a backup - because I like redundancies and because the economic rebound some speak of hasn't quite made it's way to my bank account. Chromebooks are cheap, and though I dislike having a dependency on any particular company, the Chromebook has potential. If it failed to handle what I needed it to do, I could always install Linux on it.

When Walmart.com had the Acer C7 Chromebook down to $199, I decided it was time. Having seen someone's cat destroy a Chromebook over Skype (they weren't using it for Skype), I opted for the Walmart insurance as well. For $36 it covers drop damage for 2 years (amongst other things), so all told I spent about $240-$250 after taxes. I'm a contractor. It's a tax writeoff.

My first impressions of the Chromebook were colored by my want for physically solid machines. My phone feels solid. My main work machine feels solid. The Chromebook did not feel solid, but then it's because it's light. Until now my travelling laptop has weighed in at 10lbs. I suppose I might write something up on the Acer after I've spent more time on it. I can't understand how people can write a review on a machine that they just got. That's silly. You need at least a month.

Development

I'd done my research, though maybe Google could pay Ballmer to visit their Chromebook marketing department.. The Chromebook would be called upon to handle development and, really, that's not something that the marketers of Chromebooks are intent to talk about because their main market are... not developers. 

All of these made me more confident in purchasing a Chromebook as far as work.

What most developers articles on these things don't realize is that one process does not fit all.

Since my main workflow is typically from a local WAMP/LAMP setup with Git, this may alter the way I do things a bit. Sure, I'm a Free Software/Open Source person and that goes to clients but clients don't always want their code public even though it's GPL'd - sometimes they want to maintain a Trade Secret, or sometimes they just aren't going to distribute their code. When working with and/or managing developer groups, the client's server development environment is where it all happens - though sometimes you walk into situations where unresolved office politics can leave too many keys to the server out there.

And there's always Github.

I suppose I should have expected Google to have tailored what apps it suggested based on my gmail account and google searches I've done while logged in - but I found it a bit creepy.

ShiftEdit and CodingTheWeb were the only ones I installed.

In fiddling around this weekend, I decided that so far I prefer using NeutronDrive - the main selling point to me being all the different Editor modes available and the fact that it leverages Google Drive (working a single dev project). Is it better or worse than the other IDEs/repositories? I have no idea yet, I've only really toyed with one - but the present project involves lots of use of Google Drive already. I am concerned about how multiple users editing the same file at the same time might not work well, but for one dev projects it's a workable solution.

With larger projects, it will depend on the size of the team - so it might be a development server's Git, it might be Github. It will depend on the project. With SSH on the Chromebook, it's not that difficult - and with a little network setup, I can have the Chromebook connect to a local WAMP/LAMP as needed.

The Web Developer's Achilles Heel.

No one seems to have mentioned this in any of the posts that I've read, but there's an issue with web development on the Chromebook that is the elephant in the room. Your browser. On a Chromebook, you're locked into Google Chrome - so you're out of luck for front end development. Since I mainly do back end development, it's not too big of a deal for me - but it's something that means that you can't always see what the client sees. While the machine is good for development, it's not necessarily good for evaluating browser glitches.

The Skype Issue

Skype has become a central tool for people who work across the Internet - Google Hangouts seem to be nice for some, but I have yet to encounter anyone who uses them effectively. We all know that Skype works on Android. Why it doesn't work on Chromebooks seems to have been a business decision by Google - and a crappy one at that. Here's Google's writeup on Skype on a Chromebook.

Overall

I've committed myself to working with the out-of-the-box Chromebook for a while. It's not because I like Google - I'm ambivalent about Google - but it's because I want to give it a fair shake. The lack of Skype and the inability to use other browsers is very limiting for web development work in general, but these I can work around with different machines - at least for now. The second I need to run Skype or other browsers on the Chromebook, I'll have a little entry on installing Linux on a Chromebook.

Ubuntu does seem popular for that.

 

Enhanced by Zemanta

Your Digital Signature: Who Do You Want To Be Defined By?

ConnectionsThe Web does not just connect machines, it connects people.

- Tim Berners-Lee, Tim Berners-Lee Speech before Knight Foundation, 14 September 2008

 

Often people involved in any type of Internet development need to be reminded that behind all the algorithms, IP addresses and gadgets there are actual human beings. Human beings have a different context than any gadgets to date because, despite the efforts of computer scientists to create a Turing machine, our context is different and varies from person to person.

Because of that I appreciated, 'How Facebook Builds A Dignature Signature for You (and Your World)'. It puts a very positive spin on things that anyone interested in privacy cringe. Reality is somewhere between the positive and the negative of that - something that will keep people arguing and writers with no end of content for decades, perhaps centuries. Beyond that level it gets even more interesting.

While the article talks about Facebook, it's important to note that the algorithms being discussed aren't Facebook-specific. Many websites do it - better, many companies do it. Churning behind the scenes at Google, Microsoft's Bing, Amazon.com, eBay, Twitter, Instagram and... just about anything that is 'free' to use and is popular have such algorithms churning away - getting to understand you so well that I'm surprised economists haven't clued in on the data publicly. Our behaviors, our expectations and much more are available through such sites.

When it comes to social media, it's not just about what you say about yourself. It's almost always dominated by what others say about you - and when it comes to your bank transactions, your bank is likely selling your anonymized purchase history to someone for a price.

Yet, as the article also points out, the analysis of the data can be flawed. Daniel J. Solove wrote about this in The Digital Person (2004). You can easily be persona non grata  for peculiar reasons determined by algorithms as well. It's a fickle thing, these algorithms, and it's not too hard to understand that what you connect with is determined by these algorithms. Those connections are, by and large, used to drive things to you or to determine what shouldn't be driven at you in advertising. When the government comes into play it becomes more peculiar, particularly when it has to do with governments, employers or anyone else nosey enough to pay for such data.

But again, that's not really what I'm writing about.

What I am writing about is that the algorithms for these connections constantly evolve and are becoming better at determining the small slices of reality. As the article says (link):

The trouble is that our real world — and how we describe and experience it -– is constantly changing.

User experiences and things related to user experiences are constantly evolving. As an example - when you click 'Like' on Facebook, there's an assumption being made in some algorithm somewhere about what you mean. When you retweet something on Twitter, what does that mean? That's the job of algorithms.

Before you start wrapping your head in tinfoil and locking your tapioca pudding in the locked refrigerator thinking that this is all done in top secret offices of the government or corporations bent on creating Skynet, hit pause. It happens every day. Traffic lights are a brilliant example. Actual data is used to determine the length of lights being red, yellow and green (or should be). The supermarket that has that card tracks what your purchase history is like so that they can decide what their inventory should look like. And, if you think about it, all this data is flawed in that it limited to a dataset and the algorithms that chew away on it.

As a programmer, I expect I've had more to do with this sort of thing than a non-programmer would - but it's all very real data. You might think that your medical history is top secret but if your bank is getting itemized billing for your medication, they might know more about you than you think - and that information isn't as sacred.

I'm no Luddite by any stretch, but people need to understand the responsibility of software development has increased in this context across the board. How much is too much? How little is too little?

And who do you want to decide?

Personally, I see the need for all of this on many different levels but I'm concerned that people don't understand that the data that they put out there can be eventually used for decisions that may impact their lives. The teenagers posting things on Facebook may not realize that the risque video might have unintended consequences a few years into the future when they're looking for a job.

Take a moment and think about it. It's not all bad, it's not all good - but it's definitely real. Be aware, be responsible.

 

Picture at top left courtesy Matthew Montgomery via this Creative Commons License.

Mitigating the Risks Of Google Docs and Gmail

022Once upon a time, before PCs were routinely connected to each other, smart people backed up their data on diskettes. As time progressed, they did so on CDs, DVDS and so on. The Internet came along. Some people, like Linus Torvalds, quipped about backing up via FTP to servers - an early open source methodology of sharing code instead of hiding it.

Horror stories of a lack of backup abound. It's the sort of stuff that built Norton Utilities - where the undelete and unformat commands became lifesavers for people who didn't backup things on their now ancient DOS based systems.

Now we have clouds. Data allegedly frolics in the clouds, much like toys play with each other when a child leaves the room (Tron meets Toy Story), and clouds are data services provided by companies such as Google and Amazon. With Google, companies large and small share with Google Docs and Gmail. People sleep better at night knowing that their data is being managed by corporations with user agreements that they may not have read but did agree to.

Until you get dumped by Google.

Gmail Risk Mitigation

Now, I can say 'I told you so', and that I use old school email in conjunction with Gmail - I download my email and store it on my computer. That's why I use Seamonkey. My email is only temporarily stored on Google's server and deleted when I download. To share between machines, I use MozBackup. I could leave my emails on Google's servers and hope that I somehow don't create a problem with their terms of service - which does seem to be rare but may not  be as rare as we would like to think.

Of course, I didn't get into these habits because I mistrust Google. I got into these habits when I was in the Caribbean and wasn't sure when I would have a connection. Despite what people might think, internet connections aren't as ubiquitous as marketing departments might have you believe.

And if you want to integrate some PGP, check out Enigmail.

Google Docs Risk Mitigation

For most documents I work with, there's really no need to go further than OpenOffice.org. However, sometimes people want/need to collaborate with others in 'real time' and Google Docs is good for that. Yet, again, if you need to work offline or don't want to trust all your information to Google's Great Cloud of Data, you can backup all your files - something I learned when I was working for a particular company when I was in charge of documentation. There was so much information in Google Docs and only one person responsible (me). Losing access to documents was simply something I wouldn't have happen on my watch.

Get gdocbackup. Use it.

Where's Your Data, Anyway?

As 'What Nationality is the Cloud?' points out, you may want to look into laws relating to your data as well. I'm not suggesting that you wrap your head in aluminium foil, but you probably should know the laws that govern your data - and those laws are subject to geopolitical lines on maps and agreements that have to do with who has access to your data.

Your Data, Your Responsibility

At the end of the day, there are a variety of things that could go wrong - from an obscure failure of cloud-based applications to lack of connectivity (your ISP) to data vandalism. These risks are glossed over by a lot of people because the cloud does make things easier - but it introduces new ways for you to be unable to access your data.

If your data is important then you need to treat it that way. Back it up.

While Google was the core of this article, the same rules apply to any cloud and cloud based services. Don't be the example.

Enhanced by Zemanta

Pages