April 25th, 2012

Some rambling on Push notifications.

Push notifications should be the digital equivelant of the candy rack at the check out counter. Hitting me up with stuff I don’t really need or want, at just the moment when, and in just the right way so that, I might actually buy something.

The candy rack works I think, because of it’s location and timing. Put it in any location that doesn’t have forced traffic with forced down time so that it’s noticed, and it will barely move any product.

So how do you do that with push notifications?

I think the secret comes from paying attention.  Don’t push stuff to me every chance you get, instead pay attention to what I’m doing and when I’m doing it…when you notice I’m deviating from that norm. (my norm.) by all means ‘push’ something to me to get me back on track (and then pay attention to see if my ‘norm.’ changes).

Do that, and you’ll get my “WOW”…and probably more importantly, you’ll earn MY attention…anything else and you’ll just annoy me.

April 24th, 2012

some additional thoughts on hiring.

Just catching up on a few blogs and I ran across the latest nugget* from Nate Westheimer where he talks a little bit about hiring and what he’s currently focusing on as they build the team up at picturelife.

We are just starting to build out the team a bit more at PubGears** as well, so this topic is very much on my mind these days.

At this specific moment in time, we are looking for an awesome “ad ops” person and in fact interviewed our first candidate just the other day.

The very first question I asked was “when you aren’t working, what do you do for fun?”.

I asked this because I think in the early stages of a company, and especially while the whole team is VERY small (we are only a team of 4 right now), the personality and the passion a person brings into the company is the single most important factor.

That’s not to say that they don’t need skills…but by the time we’ve asked you in for an interview, I feel pretty safe assuming you’ve got enough skills (or can fake it well enough on paper and through an initial interview) that quizzing you is mostly a waste of everyone’s time.  And really, I know anyone that has the right amount of passion and interest can learn whatever they need to make a real contribution to our efforts.

So - trying to get at the person’s passion, finding out what drives them, what would make them want to get up in the morning and be excited for the challenges they are going to face that day…and how well that fits with our existing group (both in what gaps it fills as well as what strengths it re-enforces)…these are the things we can’t get wrong in bringing in #5 to our group (or #6-#25*** really)…and so these are the things I’m also quite focused on and thinking about a lot these days.

When it comes to hiring, what do you focus on? What assumptions do you make? How much emotion do you bring to the process?

* Read Nate’s whole insightful post at http://innonate.com/2012/4/24/thoughts-on-hiring

** Yes, I realize I haven’t mentioned PubGears here yet, but now that we’ve officially closed down knowabout.it, I can finally start to talk about PubGears (the startup I joined back in December to build out the tech and help the company continue to scale/grow). So expect to hear a lot more about PubGears around here going forward!

*** BTW - if you’re a developer (or know one) looking to get involved in some really fun (and slightly crazy) stuff with me, I want to chat with you asap! We’ll be looking more aggressively to fill the role in the coming weeks, but if you’re ready now, so are we. ;-)

April 21st, 2012

Today’s random idea: mobile video review app.

Purpose: to get quick, human, feedback/reviews/opinions/suggestions on any product, brand, or service.

Basic Features:

1. Record feature: app gives user simple feature to record 30 seconds to 1 minute of video (with audio), add some quick and simple tags, and then release it to the network (basically move it into the app cloud where it awaits searches/views/votes).  The instructions around using this feature should frame the users intentions around reviewing products/services in the real world (eg. just saw The Hunger Games movie? Post a 30 second reaction/review using this app, tag it as Hunger Games, and move along). 

2. Watch feature: app gives user simple search feature that is used to search tags on submitted posts. Users can scroll through the results and watch the ones that are of most interest to them (they can then vote the ones they watch as helpful/not — a-la amazon reviews). The instructions around using this feature should frame the users intentions around getting advice at point of purchase/decision (eg. At the shake shack and not sure what to get? Search for ‘shake shack order’ and see what people are suggesting).  Bonus Feature: Allow users to narrow the search results to videos of just their friends (use existing social networks or have them build out one specific to this app — could base it on videos from the people they find most interesting/helpful within the app).

The disclaimer:

I like this idea, but it’s not something I’m going to build (or even put much additional thought into). Like many of my random ideas I get, it came to me while thinking over some other random thoughts about mobile, social, and the real world.

Most times, when I get these ideas I think about them for a bit, maybe jot some notes down about the idea in one of many notebooks I’ve got around my house…think maybe someday I’ll work on that, and then basically forget about it.

But I’ve decided rather than just let these random ideas die in notebook around my house…I might as well let them die out here on my blog instead. So I’m going to make more of an effort to jot them down and share them here going forward.

Who knows, maybe someone, somewhere can get inspired by one or two and do something with it?

So borrow the good ones (free of charge), ignore the bad, and let’s talk in the comments about everything in between! ;-)

April 18th, 2012

danlewis:

The news is behind the times.

Look at the bottom graph of the top picture. Relative to Twitter, there’s been virtually no news pickup of Tumblr.  It’s a flat blue line.  On the other hand, search volume shows that Tumblr’s been a “thing,” relative to Twitter, for almost two years. The news is two years behind.

The second picture is Tumblr v. Instagram.  Outside of the sale, Tumblr’s been crushing Instagram on search volume — steeper slope and everything.  And yet, until the sale, both “news” graphs were relatively flat. Instagram spiked — but only after the sale.

The third one show something different: Tumblr v. Pinterest.  Similar slopes, with Pinterest perhaps a bit steeper but with less staying power, it seems. The news noticed it… which underscores how invisible Tumblr is to them. But why’d they notice Pinterest? I have a few theories, none of which are flattering to the news industry.

Fascinating. And amazing. 

…the problem is that Tumblr itself is not something new (blogs have been around for a long time - Tumblr just made it a more pleasant experience to own/operate one)…additionally, using Tumblr empowers each user to build/re-enforce their own unique brand (and only slightly - if at all - that of Tumblr)…using services like Twitter and Pintrest encourage users to build the brand of  Twitter and Pintrest (and only slightly that of the user themselves)

April 12th, 2012

My basic understanding of OOP

I keep the number of mailing lists I monitor pretty small, and generally when I add one, I remove another. Lately one that I’ve got on my list and have been paying attention to is the PUG-IP (Python User Group In Princeton)…and lately there has been a small thread going on about what is object oriented programming (OOP) and how can a beginner understand and actually use it.

I find this a pretty interesting question as I remember struggling with this many moons ago as well (when I was first digging into Java actually)…and even more interesting to me is that, even after all these years of ‘using’ OOP, most of the gurus on the list agree that it’s a complex topic to explain to beginners.

I agree, and I think it’s because of two main reasons:

1. OOP involves a heavy does of theory…and truly understanding theory generally involves a heavy does of experience. That is, you’ve just got to use it, and you’ve got to break it, to understand it. That makes it very hard to learn.

2. The dirty little secret is that I’ve found in practice most OOP that people write is really just functional programming in disguise, and the talented functional programmer can have a pretty full and happy career without ever really understanding (or fully using) OOP. That is, OOP involves a lot of hype.

In fact I will freely admit that my own understanding and use of OOP is pretty basic (so please do take everything I say around the topic with a grain of salt).

Luckily being that this is the internet, and my own blog, I don’t actually have to be good at something to try and explain it to others…so without further ado, here’s my own quick and dirty explanation of OOP for beginners.

OOP is a style of programming in which you attempt to model your code after the way we attempt to explain the real world.

The 3 steps in OOP

1. Define an object

Classes are really just definitions of an object. In plain English it would go something like this:

“Do you know what a glyphon is? No? It’s a round thing that bounces.”

In code we do the same thing when we define a class. We name the class, and we set up functions (or methods) that explain the details of the class.  If you look at the group of methods within a given class as a whole, you get a sense of the definition of a class (ie. what a object of this class can do).

2. Create an object

I think this is a step that many beginners don’t really get at first, but once you get the idea that classes are just definitions of what an object is I think it starts to make sense that defining something doesn’t actually mean the ‘something’ exists. You’ve got to create an instance of that thing before you can actually use it.

In the real world it’s the difference between talking about something and actually having that something in your hands or in the physical world. In code, it’s the bit where you generally see a statement calling the new or init functions like:

my_glyphon = Glyphon()

3. Use an object

So now that you’ve defined what a Glyphon is, and you’ve actually got one in your hands, you can finally start to ‘do’ stuff with it…and that’s where your actual ‘program’ does stuff.

In the real world it’s the part where you bounce the glyphon on the floor or throw the glyphon to your friend. In code, it’s the part where you implement your program’s specific business logic.

This is another spot where I think many beginners get depressed.  It sure seems like a lot of work to have to define an object, then create the object, just so you can FINALLY start to use the object…and the sad truth is that, yes, in many cases it *is* a lot of work. And that’s also why in many cases, especially in small one-off programs (or poorly designed large programs), OOP doesn’t actually make a lot of sense.

So why use OOP at all?  Well, there actually are a few advantages OOP can give you (when done correctly and used in the proper situations). Let’s take a quick look at what some of those advantages are.

The advantages to OOP (in theory)

1. Abstraction and Encapsulation.

OOP allows you to define objects. Once you define something, you can use that definition in as many places as you want, as often as you want, for as much as it makes sense for your programs.

The true power here lies in the fact that ‘you’ don’t have to be the one that actually defines an object to be able to use it in your own programs. In fact, you don’t even have to really understand that much about the details of an object to be able to use it.

In the real world, you don’t have to know how a computer works to be able to use one. You just need to know a keyboard and a mouse help you control stuff you see on a screen. In code, you just need to know some basics about a class (what methods you can call, what parameters are needed, and what those methods will return) and you can use it.

2. Inheritance

Most fans of OOP will tout inheritance as the true reason for loving OOP…and honestly I think it *is* pretty awesome (at least in theory). In basic terms, all that inheritance means is that you can use the definition of one class to help define another class.

In the real world we use the definition of one thing to explain another all the time…”Do you know what a gazbot is? No? It’s like a glyphon but it doesn’t bounce”.

In code, there are many language specific differences here, but the basic concept is the same…without having to duplicate (much) code we can define a class as ‘like’ another class, but with a specific set of differences (the methods we define in our new class define those differences).

So in our example, when we define the gazbot class, we can say give us everything from the glyphon class, but we will give a new definition for the bounce method (which in our case we will just say, it does nothing as gazbots don’t bounce)

This turns out to be really useful as it can drastically cut down on the amount of code needed in large projects and (when done well) can make the purpose of each object and program very clear and simple.

3. Polymorphism

Of the three advantages often listed with OOP, this is by far the most complex to ‘understand’ and I also think the least actually used (or at least, the least used well). But this only makes sense, because generally if it’s hard to say, it’s probably hard to understand and use too.

Anyway - on a very basic level, all that polymorphism means is that you can define something in different ways depending on the properties it’s given.

This is complex in the real world too, but it does exist, especially in something as complex as the English language. There are many words that have multiple meanings in the English language, and it’s only through context that we determine which definition to apply.

In code, it’s actually a little easier than trying to understand English. You simply have methods of the same name, that accept different parameters…then when you call the method, the parameters you pass in determine which definition will actually be applied.

So that’s it in a nutshell.

Again, I’ve only touched on the very basics of what OOP is and how it’s used (and I’m not a guru by any means). Each of the things I mentioned above is really worthy of a much more involved discussion and can probably only be truly understood through real experience. So I encourage you to explore the web for more/better details, and even more importantly I encourage you to just start playing with OOP code. The more you do, the more you’ll start to ‘get it’.

In the meantime, I do hope this has helped at least one or two others out there…and if you’ve got corrections, updates, or questions around any of this please do drop me a note in the comments below!