5 Things You Should Know About Big Data -
A few byte-sized big data concepts (not just trivia) so that you can distinguish the substance from the hype.
While over 80% reported that they store data belonging to customers, vendors, and other business partners, only 26% reported being very confident that data stored within their organization is protected.
Social Media Explained (with donuts)
The House voted down a bill this week that would prevent employers for asking for your Facebook password.
Unfortunately, plenty of third-party websites ask for your Facebook, Twitter, and Google passwords, too. This is called the Password Anti-Pattern, and it’s extremely dangerous. Luckily, OAuth is becoming more common and is way more secure.
7 Recommendations for Data Protection by Forrester’s Andras Cser -
If content is king, context is God. DLP solutions can tell you where data is exposed, but unless you have context, how do you know where to begin? You have to be able to answer, among other things:
Learning coding from boredom -
Great post by Benjamin today.
Programmers like to program because they can do cool things.
The reason I learned to code at age 13 was so that I could automate slaying monsters in a text-based RPG that I loved. Today, I code for a number of other reasons: to earn a living, to make tasks in my life easier, to impress the ladies, etc.
Over the years I did eventually develop a deep passion for understanding data structures, algorithms, design patterns, and all the other “boring” aspects of software development. But one thing is certain — you could never have lured me into programming by teaching me about the knapsack problem or the strategy pattern.
Give me monsters and robots, then I’ll code
parislemon: Path, Not Pathological -
As an iOS lover and Path champion, a number of folks have asked for my take on the Path address book situation of yesterday and today. I’ve avoided weighing in for two reasons: first, I wanted to talk to some other actual developers about the situation. Second, the fact that CrunchFund is…
MG Seigler is great at calling people out when they a.) do something shitty, or b.) try to bullshit us. It’s one of the reasons I love reading him so much. In this case, however, Path did something shitty and MG is bullshitting us. It’s time to call him out on it.
MG’s main defense for Path stealing peoples’ address books is that they weren’t being shady, rather, they wanted to “ease the connection building process.” That’s odd. The whole point of Path is that it’s the anti-Facebook. That is, you only share your Path with intimately close friends and family. If I can’t pick them out of my address book myself, I’ve got problems a social app can’t solve.
And, by the way, how the hell is Path going to look at my address book and distinguish my best friend from my plumber? Maybe they’re stealing my phone call history, too.
OK, so let’s pretend they Path is completely benevolent (and I think they are, actually). They were storing our address book data on their servers! What if they got hacked? Most smart and security conscious developers would go out of their way not to store personal data. The minute you store personal data, you take on the responsibility for securing it.
Seigler proceeds to tell us that we shouldn’t be freaking out about Path because so many other applications take advantage of the same API. What?! He also says that Path developers were simply utilizing an option put in front of them. Browser developers have the option to grab our email passwords, but would they? Windows developers have the option to log our keystrokes, but would they? I guess some would.
Just because I leave my keys on the counter doesn’t make it okay for everyone who comes into my house to snag them and make copies. Path made a choice. They chose to be the creepy repairman that copies your keys.
Marco Arment wrote a terrific post about how his app, Instapaper, deals with the address book. Marco gets it. Could he swipe our data? Yes, but he wouldn’t dare.
Lastly, I love how MG calls it “weird” that Apple exposes your address book to developers. If this were an Android story, I think the word would be “sinister.” I’m just sayin’.
Again, I love MG and I usually agree with what he says, but I think he’s letting his loyalties get in the way here, so much so that he’s willing to be hypocritical.
Data Protection: It's Just the Right Thing To Do -
Too many business put data protection out of mind and, in the long-run, end up harming customers, partners, and shareholders. Sadly, since moral obligation clearly is not enough to make most companies flinch, state legislators have been trying to force compliance with PCI-DSS and other standards. Now the SEC is stepping in.
Last night I watched a fantastic episode of This Week in Startups with guest Aaron Levie of Box.net. Aaron is a remarkable young CEO who really seems to understand and care about enterprise software, which is a rare combination.
One of the themes of the interview was that CIOs and IT departments at large organizations are starting to embrace the cloud. Jason and Aaron discussed “bottom up” adoption of cloud-based software in the enterprise. Essentially, lower-level employees start using their favorite applications like DropBox or Evernote at work and the apps become so widespread and integral to collaboration that IT managers and CIOs adopt the technology officially.
They talked about how big Fortune 500 companies are starting to develop or acquire cloud solutions to put in their portfolios (e.g., Oracle buys RightNow, SAP buys SuccessFactors). Cloud, cloud, cloud.
Then, about 23 minutes into the interview, the elephant in the room rears it’s giant head: what about security?
Even the most progressive enterprises, Aaron remarks, have the philosophy: use any device you want (Mac, PC, iPhones), use any software you want, but secure the data at all costs.
They’d be foolish not to. We’re not talking about MP3s and funny cat photos. We’re talking about intellectual property, source code, patents, legal and HR documents, etc.
As the definition of “secure” evolves, every company is faced with hard decisions.
So what’s the solution? We have to have a security model that fits today’s distributed work model. We can’t lock everything down lest we destroy efficiency.
Levie goes on:
We have to redefine what it means to be secure and what it means to manage security. Then you move more into this category where visibility is security. If I have far more visibility into where my data is, who’s using it, every access, every event on it — maybe it’s a little more open, but people will use the product and I’ll actually see what’s going on with the data.
Secure collaboration is something Varonis (the company I now work for) has been focused on for years. If you have complete visibility into who can access data and who is accessing data at all times, then you can facilitate collaboration while avoiding the front page of Wikileaks.
Complete visibility is not a trivial accomplishment given the enormous growth and fragmentation of data:
The number one challenge is actually the sprawl that gets created with organizations — the amount of apps and data that people are now consuming and interacting with and how unmanageable that is for IT.
Varonis has been the saving grace for many of the world’s biggest enterprises when it comes to securing unstructured data. Varonis monitors every single event across your entire IT infrastructure: every file open, rename, delete, copy. Every email sent, received, marked as unread, etc. This audit trail enables us to answer all sorts of critical questions (and helps us sleep at night):
The biggest question I have for Aaron, Jason, and everyone else is how do you get visibility if your data is in the cloud? How do you audit access? How do you get visibility into who is accessing what data? Are Google and Amazon going to let us install Varonis on their infrastructure? When it comes to security the cloud is very, well, cloudy.
Photo credit: http://mp5gosu.deviantart.com/art/Cloudy-stormy-day-47828616
I remember stumbling upon tryruby.org a few years back. It was this neat little web-based shell that helped teach Ruby in a fun and interactive way.
The site lowered the barrier to entry for newcomers: you didn’t have to download anything; you didn’t need an editor or an interpreter; you didn’t even have to know what a shell was. You would simply read the instructions on the screen, type some commands, hit enter, and immediately see the results. In mere seconds, you were coding.
This was just one of why the lucky stiff’s many whimsical creations aimed at spreading the joy of coding. Nowadays, there are dozens of interactive code tutorial sites trying to do the same thing, mostly for profit. Some have even raised millions in venture capital to fuel their efforts.
One site in particular, Codecademy, reportedly hauled in 1,000,000 users due largely to their well-timed Code Year initiative, which delivers weekly programming lessons to people who have resolved to learn to code in 2012. Last week, they announced a partnership with the White House.
The response has been overwhelmingly positive: writers, VCs, accountants, lawyers all learning to code! But someone has to be the bearer of bad news:
We’re not all going to be programmers.
I promise I’m not trying to cut anyone down or dig a moat around my pristine programming castle. Those who know me know that I’ll happily teach programming to anyone who will give me the time of day. I’ve personally use sites like codeschool.com and udemy.com. I also don’t believe you have to switch professions in order to justify learning and enjoying the craft.
Confused yet? Let me try to explain where I’m coming from.
On a recent episode of my favorite podcast—Hypercritical—John Siracusa talks about the death of HyperCard. HyperCard was an application on early MacOS that let you make your own programs, or stacks, via Lego-block-style programming. HyperCard made it super-easy for normal people to build their very own programs.
The nerds thought: of course everyone wants to write their own computer programs! Why else would people want a computer in their house? We just have to make it easy enough for them.
John mentions other attempts at lowering the coding bar: AppleScript, Logo for kids, and Automator made programming more natural, fun, and easy. These platforms did, without question, make programming more accessible, but they never took off the way we geeks hoped and expected they would.
Siracusa explains (paraphrasing):
You could build up a pretty powerful system by composing all of these pieces that you didn’t write and you didn’t have to understand. But in all of these cases—HyperCard, AppleScript, Automator—the harsh reality is that anything that lowers the bar for people to do powerful things inevitably leads to Programming with a capital P.
These abstractions were leaky. The minute you try to do anything that is even slightly off the rails, you very quickly find yourself doing actual programming: conditionals, loops, composition, abstraction. These concepts aren’t natural to most people, so they stop right there. They won’t ever make the leap, no matter how easy or fun you make it.
If CPA firms had ping pong tables and Friday beer bashes, I might be tempted to learn accounting. And I would love it if there were a fun and easy way to go about it. But in the end, I could never be passionate about double-entry bookkeeping the way I’m passionate about JavaScript, because you can’t teach passion.
The percentage of the population that can engineer great software is so minuscule, and that number won’t change dramatically. HyperCard couldn’t change it; Visual Basic couldn’t change it; and no amount of instructional videos and interactive code challenges can change it. We might be able to nudge the number upward by making things easier, but there is a hard limit.
I would love to see more people from all walks of life learn to code, but I think we need to calibrate our expectations so we’re not shocked or disappointed when the dust settles and it’s just us nerds hunched over our laptops hacking away at 3am because we just can’t help ourselves.