Latest blog entries
The Art of Writing a Blogpost
Mar 09 2017 : Matias Vera
Feb 14 2017 : Felipe Ripoll
Do you need a blazing fast reverse geocoder? Enter offline-geocoder!
Jan 18 2017 : Roberto Romero
MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.
Dec 13 2016 : Sergio Abraham
20 Questions, or Maybe a Few More
Nov 16 2016 : Stephanie Goldner
Because conferences and meetups are not just about the technical stuff.
Nov 01 2016 : Pablo Villar
Sharing some light on how it is to partner with us.
Oct 27 2016 : Inaka
How to easily play a sound in Android
Oct 25 2016 : Giaquinta Emiliano
We're publishing our work guidelines for the world to see.
Oct 13 2016 : Brujo Benavides
Using niffy to simplify working with NIFs on Erlang
Oct 05 2016 : Hernan Rivas Acosta
How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.
Sep 16 2016 : Pablo Villar
How to automatically trigger rails tests with a Jenkins job
Sep 14 2016 : Demian Sciessere
A description of our usual stack for building REST servers in Erlang
Sep 06 2016 : Brujo Benavides
Using Erlang's External Term Format
Aug 17 2016 : Hernan Rivas Acosta
Integrating our Android linter with Github's pull requests
Aug 04 2016 : Fernando Ramirez and Euen Lopez
Introducing how to implement passwordless login with phoenix framework
Jul 27 2016 : Thiago Borges
Our newest game to test your Beam Skills
Jul 14 2016 : Brujo Benavides
Three Open Source Projects, one App
Jun 28 2016 : Andrés Gerace
Running credo checks for elixir code on your github pull requests
Jun 16 2016 : Alejandro Mataloni
Thoughts on rebar3
Jun 08 2016 : Hernán Rivas Acosta
Git: Not Just for Devs
If you ask, most developers will wax poetic about the many benefits of using Git. But, for all its usefulness, the concept behind it is not so well known outside of the programming world.
For the uninitiated – just to cover our bases – Git works like this: the project lives on a stable master branch. Any and all edits to the master exist on separate, cloned branches. To officially add an edit, the separate, cloned branch is "pushed" to the master branch, along with an explanation (or "commit") explaining why. The edit and its commit are reviewed by a team member, and if they are accepted, the "pull request" is accepted, and the branch is merged to the master branch.
So what are the benefits Git? Well, for one, multiple versions of a project can exist at the same time on separate, cloned branches. What’s more, the separate branches are pushed and pulled to the master branch – the official version of the project – in a controlled, systematic manner. In this way, we avoid snafus like those real-time editing run-ins on Google Docs. In the end, Git makes sure all the information ends up in a single master project.
Another major benefit is that all edits are tagged with an explanation, so when reviewing the document, you’ll know why something was added or deleted. Likewise, you can easily undo each of these tagged edits.
Essentially, Git takes the very complicated collaborative process and simplifies it to its purest form. It does this so well, in fact, that many developers wouldn’t want to imagine a world in which they had to code without Git or, for that matter, GitHub. So why should such an amazing platform be limited to just code, and why should it cater just to developers? Isn’t it time to spread the love around a bit?
But to whom? Who might benefit from Git beside developers?
Anyone, and almost everyone. Think about it. Researchers, novelists, scientists, mathematicians, teachers, screenwriters, students, any collaborative group. There are endless possibilities.
In fact, a 600-page textbook on Homotopy Type Theory was written in less than six months by a few dozen mathematicians. And they used GitHub.
Loren Burton followed their project through its many iterations. Granted, it took them a while to get the gist of Git, but once they did, there was no stopping them, and what they did is nothing short of amazing. Maybe the best part? They can iterate new editions without breaking a sweat.
Because it is so useful, Git is slowly and surely finding ways to appeal to non-developers. But Git wasn’t designed with non-devs in mind. So here we are, to discuss the possible obstacles of using Git as a non-dev and highlight a few projects that are working towards making Git more accessible.
Obstacles of Git for Non-Devs
Git is great, and GitHub makes it even better. But it’s easy to forget how hard Git is to learn in the first place, especially if it isn’t a cornerstone of your work or office culture.
For one, tech jargon is especially alienating for those who have no tech background. This problem can be easily solved through implementing a more friendly user interface and finding different metaphors for command-line references in particular.
Another seemingly minor obstacle is that edits in Git are typically changed and marked line-by-line. That is to say, if I change one letter on a line of code, the entire line will be marked as deleted and then re-added, the latter version containing my edit. But this won’t work well for writers. A non-dev-friendly Git program would need revise the variable of change to phrases, words, and possibly even letters, not whole lines of code.
Something else to consider is the disciplinary aspect of Git. Those used to Git will find it easier to remember to upload each and every change, but this may prove difficult for others. If they aren’t used to the interruptions, it may even block whatever "creative flow" they have in the moment. This can be solved in any number of ways, either by sending reminders or automating the commits so that the user can forget about them altogether.
In exploring how to bring Git to non-devs, these obstacles need to be addressed and re-imagined, all while maintaining the benefits of using Git in the first place.
As far as Git for non-devs goes, nothing is as big or all-encompassing yet as GitHub, but people are chipping away at the idea. If Git interests you beyond coding, here are a few programs that are worth checking out:
Draft, for one, offers easy version control and other collaborative tools for users. When others propose edits to your personal project, you can decide to merge or ignore. It also bookmarks different versions of your work, and you can even examine how your document has changed over time by comparing these versions side-by-side. On top of that, there’s an Uber-like service for copy-editing. Simply click the "Ask a Professional" button for free advice, no matter if you’re writing a Christmas card, a wedding toast, or a piece of historical fiction.
There’s also Editorially. It, too, is presented in plain text so you can worry about the words more than the format. It also enables you to compare any two versions side-by-side, just as Draft does. You can hold discussions with your peers in the margins, and you can easily see who has said and changed what in the document. Editorially is always on auto-save. Plus, its responsive design will work on any of your devices.
Authorea is yet another program, developed by "a spin-off initiative of Harvard University." It has many of the same features, and its engine understands Latex, Markdown, and most web formats. It works online, too, rendering your articles into HTML5 right in your browser. The first article is free, but to use Authorea for more than one project, you’ll need to get a subscription.
A fourth program called Penflip is underway, too. It is one of Loren Burton’s projects. For now, it’s just a landing page, but based on the great ideas in his blog post, I’m sure it is worth receiving the updates.
Git is as popular as it is with devs for a reason. It is a simple and systematic way to create large, detail-oriented, collaborative projects. If this seems in any way useful to you, don’t shy away. I encourage you to look into one of the non-dev-friendly Git-based programs, because Git will change the way you think and write with others for the better.