RT

"Life begins at the Edge of your Comfort Zone" - Neale Donald Walsch

[natural-affinity]

Mindset

Every once in a while a book comes along that you just simply can't put down; Mindset, a psychology book by Dr. Carol Dweck, is one of those reads.

The book describes two types of mindsets that people can adopt, Growth vs. Fixed, and simply by knowing both, you open the door to change.

However, perhaps the biggest draw of the book is reading about the actions people take while in a particular mindset, and being pleasantly surprised by which category you think you fall into.

For example, those who adopt a growth mindset:

Are full of gratitude

Constantly want to upgrade

Ask how? Not is it possible

View setbacks as a wake-up-call

Praise the effort not the person

Believe that abilities can be cultivated

View real self-confidence as a readiness to grow

Believe people can change if they really want to

When depressed, exhibit increased action to fix it

Love what they are doing, even in the face of adversity

Find it inconceivable to want something and do nothing

And those with the fixed mindset:

Are full of bitterness

Keep mental counters of daily wins

Surround themselves with worshippers

View themselves as a finished product

Worry about perceptions over realities

Don't want to expose their deficiences

Expect flawless perfection, right away

See others' successes as their failures

Are the genius with a thousand little helpers

Fear trying and failing without an excuse

Believe you need effort OR ability, not both

Rely on blames, execuses, and the stiflings of rivals

Spend too much time on things to enhance public image

See others' potential as a threat to unmask their flaws

Only want feedback about their abilities: Right or Wrong

May seek weaker obstacles, to improve superiority complex

When they think they are smarter, they treat others harshly

Believe that one failure can define them; every mark matters

Study in an earnest, but superficial way, then hope for the best

Lose focus when things go wrong and put their dreams in jeopardy

Memorize like a vaccuum cleaner instead of learning for understanding

Like quick results to meet expectations, rather than pursue the new

If any of above sound familiar, you'll instantly realize what camp you fall into with certain aspects of your life. Of course, as long as you are willing, you can always change your mindset. Here's how:

Discover the joy of learning

Drop the good-bad, strong-weak thinking

Change your framework from judging to learning

Use every [ethical] strategy possible to help yourself succeed

Vowing never works. Make a concrete plan you can visualize

Remember, if you catch yourself falling into a fixed mindset, realize that you are actually making your confidence more fragile, which in the long-run, will create a self-defeating cycle. The fixed mindset lures you with the promise of a lifetime of success just for sitting there, while the rest of the world moves forward; if you think that sounds too good to be true, it is.

[natural-affinity]

Don't find fault, find a remedy.

Henry Ford

[natural-affinity]

Write smart not hard

Great advice for business writing from Scott Adams. Here are his guidelines:

Keep it simple.

Use short sentences.

Be clear and persuasive.

Get rid of unnecessary words.

Your first sentence should grab the reader.

[natural-affinity]

Storify Gem Part 6: Aggressive Refactoring

While some might say the refactoring session(s) should have come sooner or more often, our deliberate decision to delay has actually created a new opportunity: Most of the applications we deal with on a regular basis at work already have legacy code assets, which means that we need to figure out how to aggressively refactor them without breaking any existing functionality. Although we've put ourselves in the most painful situation, we've actually set ourselves up for one of the most practical learning experiences. And that's what really matters. I think Sandi Metz said it best:

Refactor not because you know the abstraction, but because you want to find it.

-- Sandi Metz

Tools of the Trade

To help us refactor, primarily, we must follow methodologies such as TDD, and principles such as DRY and SOLID which represent the set of rules designed to help us systematically dig our way out of technical debt (or prevent it in the first place). Other tools such as static code analyzers like Code Climate, techniques such as meta-programming and DSL creation, testing tools such as web-mock and VCR with continuous integration servers are all designed as complements to these principles and will help facilitate the process.

Taking the bull by the horns

Before we start, let's design an action plan:

Step 1: Review our SOLID principles.

Step 2: Determine where we think the biggest code smells will be.

Step 3: Use Code Climate to verify our assumptions.

Step 4: Correct the smell via TDD, test tools, new paradigms.

Step 5: Rinse and Repeat until done.

How do we know when we're done? SOLID should give us an idea, and code climate should support this notion via its GPA metric. So let the refactoring begin! Stay tuned for updates on my findings.

Storify Gem Part 1: It started with a tweet! Storify Gem Part 2: Minimum Viable Product Storify Gem Part 3: Technology Choices Storify Gem Part 4: Enhanced Domain Modeling Storify Gem Part 5: Asynchronous API Pitfalls

[natural-affinity]

Either you make the commitment to get results or you don't.

Mark Cuban

[natural-affinity]

Storify Gem Part 5: Storify Asynchronous API Pitfalls

It has been an exciting couple of days and I'm proud to announce that as of Dec. 16, I've implemented all operations supported by the Storify API (even some of the un-documented ones). Now is a great time to take a short break from coding, and share my thoughts regarding the integration experience. Like most APIs today that need to meet modern scaling requirements and achieve near real-time performance, Storify is using an asynchronous backend architecture. Specifically, a quick curl command reveals the following:

HTTP/1.1 400 Bad Request Server: cloudflare-nginx Content-Type: application/json; charset=utf-8 expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.storify.com; X-Cache: MISS X-Cache-Server: storify-api03 Via: 1.1 varnish x-powered-by: Express

They are Node.js shop using the Cloudflare CDN, varnish caching engine, nginx HTTP server, and Express.js, a Sinatra-style framework to achieve high performance. If you haven't worked with async technologies before, the fast performance is achieved due to its non-blocking nature; however this also implies that actions may not take place in the order you would expect...

Non-blocking and Post-Processing

Creating a Story: In this scenario, we get back a response almost immediately, which includes our original JSON request plus a unique sid and slug for the new story. However, the story literally takes a few seconds to be created. In other words, a background persistence job is being used. Additional the SLUG may not be the real slug. I witnessed a situation where the slug id was incremented to the point where you had to manually check the GUI or master list of user stories. Perhaps a queue-failure-retry situation? Publish on Create: When managing a story, as with most publishing platforms, there are two states: working and published. If we ask Storify to create and publish right away, the results are not what you would expect. You can literally watch the user's list of stories via the API and wait until the story finally appears. The solution feels like a two-phase approach: First stage as a working draft, then publish and expose, instead of as a single operation.

Editor-Centric Design

The platform feels like it was designed as a web-service, but the calls were centered more around the editor, and were later exposed as an API which isn't the same as designing an API from the start. Using the create and publish example, if I follow the create operation immediately with a GET story call, it actually fails. Meaning that the async backend actually hasn't gotten to the persistence step! To make it work, every client would have to follow a create by a get-wait-retry loop for a few seconds to determine when the story is accessible. Moreover, if you create a story in working draft mode via the API you are actually out-of-luck. I tried accessing a story that was in draft mode to no avail: slug not found. Perhaps I'll poke around with Firebug again, but this is a huge miss on their part. I agree, un-published stories should not be accessible to anyone, except the original author. From a domain modeling perspective while the JSON content structure for story elements are quite extensive and rich, unfortunately, it feels like the meta-data from the different content sources has not been mapped to a generic content model:

"metadata": { "data": { "commentCount": 3405, "viewCount": 3318753, "ratingCount": 20335, "rating": 4.901844, "aspectRatio": "widescreen", "player": {}, "description": "....", "title": "...", "category": "Film", "uploaded": "2013-10-01T12:59:53.000Z", "id": "OPVWy1tFXuc" }, "apiVersion": "2.1"

I feel as though a better use of the adapter pattern could have helped to achieve this rather can relying on client applications to guess the structure. JSON schema anyone?

Fixing the Design

I've worked with a lot of near real-time systems writing SOA-EDA (MQ) backends, and this type of behavior isn't what you'd expect. Typically, client applications would perform a get w/wait when dealing with a single operation, never across multiple, distributed operations. With the current design even an AJAX request with a callback would have the same problem: The response from the create would return immediately with a 200 OK response, and the second get story call would return immediately with a 404 story not found error. If the story really has been created, then it should be available as soon the next get story call is issued. To fix the issue without blocking, Storify could augment the design with a publish-subscribe model or a server-side push whereby clients are later notified when the story becomes available.

Storify Gem Part 1: It started with a tweet! Storify Gem Part 2: Minimum Viable Product Storify Gem Part 3: Technology Choices Storify Gem Part 4: Enhanced Domain Modeling Storify Gem Part 5: Asynchronous API Pitfalls Storify Gem Part 6: Aggressive Refactoring

[natural-affinity]

Don't let yourself be lulled into inaction.

Bill Gates

[natural-affinity]

Storify Gem Part 4: Enhanced Domain Modeling

Now that the MVP is done, our gem is done! Wrong. Not even close. Building a software library is like having a baby (or so they tell me), the inception was actually the easy part; raising it to maturity is a whole other ball game. So is it time to address our technical debt? Perhaps, but I know for a fact that we will have an opportunity to perform some refactoring soon enough. That's the interesting part about software design is that things have a way of revealing themselves; the sooner you recognize the patterns the sooner you know what action to take.

Completing the API

Instead, I have made the decision to continue implementing the rest of the Storify API. From the documentation, we can see that there are about sixteen unique endpoints. However, if you look closely, there's already a pattern starting to emerge: at least seven endpoints return a list of stories. Recognizing this will provide us with an inline refactor opportunity, thereby allowing us to implement several API calls with little overhead. However, the full API also reveals two limitations in our MVP:

We need a way to send JSON in order to push updates

We need a complete set of domain models to represent the content

Notice I said limitations, not deficiencies. To meet the MVP requirements, we only had to deserialize part of a story and part of its elements to render the output. Making these types of calls early on will help you to ship your product faster, and as new features are implemented, your next steps will be prioritized automatically.

Model and Serialize

So how do we solve our problem(s)? Actually, domain modeling and serialization are two sides to the same coin, and are quite common challenges that developers face. For rubyists, a great choice is Representable. It's a gem that utilizes the Decorator Pattern, whereby our domain models are enhanced to include a JSON representation among other definable properties. This implies that once we fully define our object graph we will be able to serialize or deserialize at any level:

require 'representable' require 'storify' # build a story from JSON story = Story.new.extend(StoryRepresentable).from_json('{ ... }') # build a story directly story = Story.new.extend(StoryRepresentable) element = Element.new.extend(ElementRepresentable) element.data = StoryData.new.extend(StoryDataRepresentable) element.data.text = "Adding a new text item!" # append element to story story.elements << element # serialize the entire story (including sub-objects) story.to_json # serialize just the element (including sub-objects) story.elements[0].to_json

This is exactly what we need. All that's left is to abstract the need for users of our gem to create each nested type, as this requires intimate knowledge of the underline domain model, which shouldn't be a requirement. But let's not get distracted, abstraction techniques with DSLs, meta-programming, etc. will come later. Onward!

After a couple of hours, we now have over 40+ models that represent our domain object graph beautifully. Time to push to Github and share with the world, and then continue with the rest of our API implementation.

Storify Gem Part 1: It started with a tweet! Storify Gem Part 2: Minimum Viable Product Storify Gem Part 3: Technology Choices Storify Gem Part 4: Enhanced Domain Modeling Storify Gem Part 5: Asynchronous API Pitfalls Storify Gem Part 6: Aggressive Refactoring

[natural-affinity]

Learn from everyone. Follow no one. Watch for patterns. Work like hell.

Scott McCloud

[natural-affinity]

Storify Gem Part 3: Technology Choices

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.

Storify Gem Part 1: It started with a tweet! Storify Gem Part 2: Minimum Viable Product Storify Gem Part 3: Technology Choices Storify Gem Part 4: Enhanced Domain Modeling Storify Gem Part 5: Asynchronous API Pitfalls Storify Gem Part 6: Aggressive Refactoring

[natural-affinity]

Decisions are temporary so make the call and move on

37 signals

[natural-affinity]

Storify Gem Part 2: Minimum Viable Product

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.

Storify Gem Part 1: It started with a tweet! Storify Gem Part 2: Minimum Viable Product Storify Gem Part 3: Technology Choices Storify Gem Part 4: Enhanced Domain Modeling Storify Gem Part 5: Asynchronous API Pitfalls Storify Gem Part 6: Aggressive Refactoring

[natural-affinity]

Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.

Steve Jobs

[natural-affinity]

Storify Gem Part 1: It started with a tweet!

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.

Storify Gem Part 2: Minimum Viable Product Storify Gem Part 3: Technology Choices Storify Gem Part 4: Enhanced Domain Modeling Storify Gem Part 5: Asynchronous API Pitfalls Storify Gem Part 6: Aggressive Refactoring

[natural-affinity]

It’s not in the dreaming. It’s in the doing.

Mark Cuban

[natural-affinity]

Finding Rogue Bytes: The Hunt for Nulls

We had an interesting case with our XML Schemas within our WebSphere Message Broker MessageSet, whereby the mqsicreatebar command would essentially crash (i.e. the JVM would run out-of-memory) during compilation. We found that one of XML schemas in the dependency chain contained a NULL byte in place of a closing slash for an xml tag. 

(i.e. <NULtns:element> instead of </tns:element>)

To give you an idea, our Message Set folder structure was organized as follows:

[project name]

| +- [project name]

|      +- messageSet.mset

|      +- [com]

|          +- [esb]

|              +- [namespace]

|                  +- [schema1]

|                      +- *.mxsd

|                  ...

|                  +- [schemaN]

|                      +- *.mxsd

As such, I decided to write a quick script we could use to recursively search all schemas within our messageSet project for NULL bytes.

https://github.com/natural-affinity/nullfinder

[natural-affinity]

Hello World

Let the blogging begin!