Observables are a way to model push-based data sources such as DOM events, timer intervals, and sockets. Ben Fischer walks us through properties of this model in depth including how to create, filter, combine, and transform streams. He will also highlight situations where using Observables in web applications makes the most sense.

For more videos, visit our new Videos channel.

Matt Aimonetti shares lessons learnt during his quest to find the right technology to build software at Splice.com

For more videos, visit our new Videos channel.

Ben Manns, Software Engineer at Doximity spent some time a couple weeks ago giving the team a talk about using Apache Kafka and Samza to automate ingestion of database changes. The use-case of his talk was about leveraging Samza to watch MySQL binary logs and Kafka as the pub-sub messaging system to update our Elasticsearch indexes with the proper updated documents. Checkout the video of the talk below.

For more videos, visit our new Videos channel.

Having a defined workflow has huge advantages. It adds discipline and structure to a process, helps focus on one task at the time, and a whole lot more. Here at Doximity, the mobile team has honed one of its workflows by applying a general convention for branching and pull requests on Github. This convention is great because it leads to structured and manageable repositories. But, as you’ll see below, it can be a bit labor intensive.

Let’s start with a look at a branch graph of a repository. It usually looks like this in its most basic form:

In this process, the changes for each feature are code reviewed on their own pull request to the version branch. And each merge to the Master marks a new release.

It looks simple, but just imagine what you need to do in order to create a pull request for a simple one-line fix on the code.

$ git checkout -b new_branch_name
$ git add -A
$ git commit -m "commit message"
$ git push --set-upstream origin new_branch_name

After all that, you’d open up github.com and create a pull request from the site. At Doximity, we also link the created pull request with its corresponding story on Pivotal Tracker by putting the story link in the PR, and vice versa.

To me this is way too much work for committing a single line change. It’s also really redundant for major changes. Thankfully, there’s a tool to help.

Introducing PRH (Pull Request Helper)

Pull Request Helper (prh) is a simple python command line interface (CLI) application. It uses subprocess in python and an API from hub to do all that work above with a simple and easy command. The equivalent of the above process with prh is:

$ prh -b new_branch_name

That’s all there is to it! In the process, prh:

  • created a new branch called new_branch_name
  • committed all the changes (with the default commit message)
  • pushed the commits to origin
  • created a pull request using hub API (with the title of "new branch name")
  • opened the pull request in a browser

But wait. What about linking the story to the PR? For that, all you need to do is use -m option and add a link to your story, like this:

$ prh -b new_branch_name -m https://your/pivotaltracker/story/link

You can see the results on Pivotal Tracker as a comment on the story:

You can also see it on your PR as the pull request body:

The case above is only one of many supported by prh. You can also use it to create a PR when you’re already in a feature branch (using -upto option) or even commit your code in a new branch and create its PR to another branch (using both -b and -upto together).

There are many more options for customization. These include -pb for adding a message to the pull request body and -pt for changing the default pull request title. Or, if you wish to add just one of the changed files, you can use -a option with the file’s path.

No matter how you customize, automating the committing process using prh will save time and prevent mistakes.

To read about all the customization options and download prh visit PullRequestHelper.

Looking Forward

We wrote prh with extensibility in mind. That means it won’t take much for you to fork the repository and make it match your existing workflow with some simple modifications.

Pull Request Helper is an open source project. You can contribute by adding and improving the code, requesting features, or reporting bugs. And don’t forget to check out the requested features at the issues page of the project. Thanks and enjoy prh!

Dependencies

python 2.7
hub


Get started using PRH

Learn more about Vital
Get started using Vital
Integration with Rails: Ruby Gem


Another Front-End Framework... Why?

With an abundance of well-known options that are backed by years of refinement, why reinvent the wheel?

The answer is simple: The wheel doesn't fit.

The Problem

The allure of quick setup drew us into experimenting with Bootstrap in some applications. Setup was easy, but maintenance was not. We spent more development effort that we would have liked to tackle simple problems.

Customizations to meet business requirements became difficult. Since there was already so much code and structure in the original framework, customization always resulted in excess amounts of code. This made for an unpleasant and unmanageable code base. There were also too many framework options and features that went unused.

While we could have customized the build to decrease the size of the footprint, the complexity and size of individual components was still too great. Massive frameworks like Bootstrap and Foundation were just too bloated for us.

Get Real

The issue became real several years ago when our early stage startup went from having to maintain one application to about ten. We needed a custom solution that could scale as fast as we did. So we decided to continually develop and maintain our in-house framework.

Productivity

Productivity was a key factor in the formalization of Vital. As the need for a multitude of small applications grew, so did our users demand for mobility. The framework needed to encapsulate easy mobile optimizations while still maintaining desktop friendliness.

Some things we wanted out of Vital:

  • Light enough to load and render quickly on slow cellular networks
  • Scalable on all devices and screens
  • Easy to read, write, and maintain
  • Quick to compile and refresh locally
  • Customization friendly
  • Doesn’t require heavy nesting, structures, or classes

Efficiency

Everyone writes code a little differently, and that’s okay. But when working in a team, code should be somewhat consistent. We wanted to allow code style to be flexible enough for individuality in code, but rigid enough to minimize technical oversight. This allows new and existing team members to work efficiently.

Mobility

Our mobile usage exceeds our desktop usage, so we wanted to keep Vital lightweight and optimized. We integrated the ability for each application to generate custom font iconography, keeping HTTP requests to a minimum. In addition to being quick, most form elements render consistently while gracefully degrading on legacy browsers - a huge plus for branding.

At just 22 KB minified, the Vital CSS framework is very small. Vital is also written almost entirely in em values, so scaling is easy and the code remains minimal.

Size Breakdown:

Size Gzipped
CSS Framework 22 KB 6 KB
Icons (.svg) 3 KB 1 KB
Icons (.eot) 2 KB
Icons (.ttf) 2 KB
Icons (.woff) 2 KB
Javascripts 0
Total 31 KB


Did We Make The Right Choice?

Simply, yes. When our business requirements change, we pivot faster than ever. Writing and editing has never been easier. Maintenance across various applications has been minimal. Vital is currently integrated into all of our applications that have a UI. Each application is fully customized to meet user and business needs.


Learn more about Vital
Get started using Vital
Integration with Rails: Ruby Gem