#startupdigest

Hace unas semanas Osvaldo Ayala, miembro activo y apasionado también de Monterrey y su comunidad emprendedora, me invitó a ser junto con él ser curadora de Startup Digest.

Estaremos subiendo a un calendario todos los eventos de tema emprendedor en Monterrey, nos podemos enterar de la mayoría de esta oferta pero es evidente que no conocemos todo lo que se ofrece. Aquí viene lo interesante, cualquier persona puede subir su evento al calendario, cuando esto sucede nosotros lo que haremos será publicarlo.

Si no me dedicara a esto del mundo emprendedor y me topara con toda la oferta de eventos que hay posiblemente, por mi forma de ser, me confundiría... Para nuestra no fortuna a veces se empalman.

Está increíble que cada semana tengamos la opción de asistir a varios eventos en la ciudad, lo complicado como usuarios es cuando tenemos que elegir a cuál de estos foros ir.  Y si a esto le sumas los compromisos y cosas personales que cada persona tiene se vuelve aún más complejo. 

Para mí es una ventaja que en un solo lugar estén concentrados todos los eventos, así puedo organizarme y decidir a cuál asistir. Recordemos que el emprendedor anda en 1,000 y 1 cosas, al presentarle la información organizada y condensada todos salimos ganando.

Como agente del ecosistema, al organizar eventos por respeto a la misma oferta y los otros organizadores es una atención y detalle considerar los foros previamente organizados... Siempre pensando en que el que se beneficia es el emprendedor.

Con frecuencia me piden difusión de eventos a través de este blog y el Fan page que hice... Con gusto lo voy a hacer pero también los invito a tomar más acción y responsabilidad colectiva al participar en Startup Digest, juntos podemos lograr que esto crezca y nos entendemos a través de esta página de las opciones que tenemos, además está increíble que puedas agregar el Google Calendar al propio.

Starting this week, I'll be curating the brand spankin' new #media edition of the StartupDigest newsletter. Yay!

What is StartupDigest? It’s a series of insider newsletters covering all things startup across different regions and verticals. Find out more: http://startupdigest.com

If you sign up for the StartupDigest Media Reading List you’ll get a weekly round-up of media about startups and innovations from the media industry in your inbox. You can do that here

For me, the driver has always been about two things: Solving a real problem with the right tools, and the challenge of learning new technologies in a highly compressed timeframe. For our Storify solution, the beauty of working with SOA and SaaS is that you actually have a lot of flexibility when it comes to choosing a technology stack. Since our focus is building a service consumer, the emphasis on the "right" matters even less. So go with what you want to learn.

Unleash the Rubyist

It's no secret that I'm a huge fan of the Ruby language. Maybe its that flexible, english-like syntax, the way the rspec/cucumber test cases read, or the Japanese influence that resonates with me so well, but I've always found it the most exciting to work with. That being said, while we could write a quick, single-purpose script to build our MVP, I'm a firm believer in the the bigger picture: a reusable open-source library. In the Ruby world, this means that we need to create a gem. If you've never done this before, the best place to start is with this article from Mr. Ruby gems, Nick Quaranto @qrush. The beauty of this approach is we can give back to the community via open-source and at the same time, incur almost zero overhead while building our MVP.

Hacking the MVP

So after about a day's worth of effort, I managed to build our MVP, share it on Github, push it to RubyGems. The icing on the cake? After a few hours later with 60+ downloads, my tweet was also read and favorited by the man himself:

@JoshuaBaer hacked together a quick @Storify #rubygem w/text output. #startupdigest featured in doc sample: https://t.co/XFlu2trGch

— RT (@n4ffinity) December 10, 2013

Very cool! In some ways Twitter is an even better networking tool than Linkedin. As for the MVP, for the most part I stuck with our basic requirements. However, I did sprinkle a few garnishes on top since the cost was very little effort, but the value-add in terms of visual impact was enormous. e.g: Using Nokogiri to strip the HTML tags/entities out of text

doc = Nokogiri::HTML(desc) desc = doc.xpath("//text()").to_s

e.g: Using inherent Ruby magic to underline titles

out << '-' * @title.length

e.g: Prepending an '@' symbol to Twitter usernames

username = "@" + source.author if source.name == 'twitter'

Success aside, it is now extremely important to take note of the conscious trade-offs we made along the way, since these have become potential sources of technical debt. Specifically, from a testing perspective, what we really should have used was a library such as VCR to record and replay Storify API responses, web mocks, or factories to enable cleaner CI server integration, and avoid making API calls for every test. However, realize that while building an MVP in a compressed timeframe, what we actually need is live-feedback against the API via acceptance testing, so that we can debug any nuances immediately. These test are still valuable to have, but shouldn't be the primary source of testing long-term.

Okay... so the Steve Jobs quote is slightly out-of-context. Nevertheless, it helps to illustrate an important point. If we're going to get this product out the door, we need to focus on just the right amount of features that will solve the problem.

Requirements

From the tweet, we know that we need to produce a text-version of a Storify post. However, further analysis of the Storify API reveals that at a minimum, we also need:

We need a developer account: username and API key

We need to retrieve an authentication token

We need to retrieve a story for a particular user

We need to consume JSON via a REST API

We need to serialize the JSON as text

We need to support paging

We need to capture basic story meta-data

We need to capture basic story content or elements

From a domain model perspective:

Story: Title, Author Name, Date Published, Permalink

Story Element: text or other (date, link, author)

Trimming the Fat

So what did we cut out? Everything else. All other API calls, extra story and element meta-data, and even the tweet text! But isn't the tweet text important?!? Absolutely. Long story short, the web solution at Storify seems to be using a deprecated version of the API as such, the rendered JSON actually has the tweet text. However, the version documented on the developer site returns JSON that only includes partial text, and oembed links (perhaps due to the Twitter V1.1 API changes). I'm not a fan of building against a deprecated API -- they could decide tomorrow or ten weeks from now to decommission it. Not to mention we'd have to go resolve each tweet via extra Twitter API calls. The book Getting Real by @37signals put it best:

It just doesn't matter. Decisions are temporary. So just make the call and move on.

-- 37 signals

The extra integration endpoints speaks for itself: Drop the feature.

After being introduced to the Startup Digest series just over 2 years ago, by a friend and fellow entrepreneur, @nagibtharani, and working for some companies in Buffalo, NY, it’s no secret that I’m a huge supporter of the American entrepreneurial spirit and their progressive attitude towards solving problems and embracing new technologies.

As such, I’m always looking to build something cool but practical. For me, that opportunity recently came in the form of a tweet from Austin Startup Digest founder @JoshuaBaer:

I’m looking for a volunteer to write a script that takes a Storify story and creates a text version for the Austin StartupDigest (please RT)

— Joshua Baer (@JoshuaBaer) December 9, 2013

My first thoughts on Storify: Man this is cool!

The Competition

First order of business: due diligence. There was close to nothing. No scripts, libraries, SDKs (i.e. no real solutions). So what are we waiting for?! Let's get started!

The Engineer's Dilemma

Every Software Engineer who is passionate about their work hears that small voice in their head that obsesses over the same things:

The folder structure isn't perfect...

The class and method names don't sound right...

I wrote my tests after the code. There goes TDD...

If you're a fan of Dragon's Den, Shark Tank, or entrepreneurship in general this is the part where you should hear Kevin, Mark, or Robert say:

What were you doing for the last 9 months?!

Where are your sales?!

Why haven't you built it yet?!

Perfectionism is great, but don't ever let it stop you. Focus on execution and delivery.

Leading the Charge

Remember that the window of opportunity is often very small. @JoshuaBaer has over 13k+ followers and runs @CapitalFactory a startup-accelerator, in the heart of Austin, TX, an entrepreneurial powerhouse city. I figured I had a day or two at most to make an impact before someone else does.