herraiz.org | Blog
My blog works using Jekyll and Org Mode, along with a Git repository. Every time I push a new org file to the repository (a new blog post), it gets translated into HTML by Emacs, and published in the web.
This is very cool, as I can write in the blog while I am offline, and just push the changes whenever I get online again.
But there is a big drawback: I can only post from devices that run Emacs.
In the last months I have started to write more and more with an iPad, and I have always felt that it really sucks that I cannot post in my blog directly from the iPad.
After some investigations, I think I have found the setup that will allow me to write from the iPad, and maybe, this can also mean that I will revive my blog.
In order to publish a blog post from the iPad, I need two pieces:
- A text editor, with nice syntax highlight if possible
- A Git client, that allows to push to my personal repo using SSH
I have not been able to find a text editor with Org mode syntax higlighting. But other than that, Textastic is just working fine.
It integrates very well with Working Copy, a very nice Git client for iPad. This app allows to commit in a local clone in the iPad, and then push to my server.
So now, I can write the Org file in the editor, save it in Working Copy, commit and push it. The hooks in my cloned repo at the server, where Emacs and Jekyll are installed, just take care of the rest.
Written on Jul 03 2016 | Comments »
I have been always convinced of the criticality of recruiting for a team to be successful. If you don't hire the best and the brightest, you are wasting everyone's time. Recently, I stumbled upon a blog post with that very same title.
You may think (as I did until not a so-long time ago) that the solution to this problem is just putting the barrier very high. However, there is trade-off between getting the people you need, and putting the barrier too high. You might be hiring the truly best and brightest, but if they are just a few of people, or you take too long to hire, then you are not solving the problem.
The solution? Open your focus, and hire globally, but you don't have to relocate people, just let them work from their places. This is of course like discovering the Mediterranean Sea, many open source projects are working in globally distributed teams.
However, making a remote team work like a team is not straightforward. You have to setup the proper environment to allow the team to work, regardless of where is everyone located.
The post contains a thorough piece of advice on how to achieve this; I have particularly liked the following ones:
- ”Enable people to leave a record of the useful things they’ve done. Not a 'to do' list, but a 'done' list.”
- “ Don't lock important information into water cooler chats and hallway meetings where nobody except the locals who happened to be in earshot benefit.” (or in emails to specific people, share information using mailing lists, or forwarding messages to lists if they contain relevant information)
- ”Every time you see something like this arrive in your inbox, you better believe in your heart of hearts that it contains useful information. The minute these posts become just another "whenever I have time to read that stuff" … you’ve let someone cry wolf too much and ruined it. So tread carefully here. Everything that gets shared in this public discussion space has to be Need to Know.”
- ”Never underestimate the power of actually talking to another human being.”
- ”Monday Team Status Reports: Every Monday, every team at your company
(even if you just have one) should produce
a brief, summarized rundown of:
- What we did last week.
- What we’re planning to do this week.
- Anything that is blocking us or we are concerned about.”
Many of these suggestions can probably be useful too for teams that work in the same physical location.
Some of this advice can be easily implemented in a team using tools such as a wiki (e.g. Mediawiki) and project management software (e.g. Redmine). Of course the crucial issue is not having these tools installed, but fostering that everyone share the vision on how to organize the team, how to report activities, the importance of sharing information, etc. In short words, fostering this culture of work.
Written on Aug 11 2014 | Comments »
The Big Data hype, the cool visualizations of data, the popularity of Hadoop for data processing and other sophisticated tools can make us forget that the one of the most powerful data science tools has been at our fingertips since decades ago.
Many data wrangling tasks can be done directly in the shell using UNIX commands that are older than most of us. This session at the Strata conference has reminded me of this once again.
Handling data using shell commands is probably faster than other options (e.g., a Python script), but it also helps fulfilling a (IMO) crucial requirement for all the code that we write to do data science: it should even work in the MIR.
Yes, the MIR, the Russian space station.
When NASA realized they had to collaborate with the Russians to get their people and experiments in space, they had to design everything to work with the MIR. Being so old-school, designing for the MIR required some extra effort and even sometimes it seemed kind of outdated. But the benefits clearly outweighed the additional required effort. Americans experienced an important reduction of the number of problems they had to face when everything was already in space and there was no turning back (*).
In our case, to make our code to even work in the MIR, we should always ask ourselves questions such as:
- Will this code work unattended in a server even if it fails for some of the cases?
- Can I extend it to more cases/files without touching the code?
- If I give my code to a third person, instead of hating me, will she/he love me? (it is documented, commented, etc.)
- And probably many more questions…
Fulfilling all these requirements is of course not straightforward. I know sometimes making things work in the MIR can be painful, discouraging and disheartening. After all, it works in your laptop, why should you bother making it MIR-compliant?
Americans asked themselves the same all the time. The answer was either you do it his way and get your stuff in space, or you keep your stuff in Earth and watch the Russians progress in the space race. Eventually Americans ended up doing their own space station. I suspect because all the cumbersome to make things work in the MIR.
So even if we have Hadoop, Spark, Graphlab, Mahout or any other modern and sophicasted tool. Or even if we don't have it but intend to get there doing research and workin towards getting our own space station, we should never forget the shell to make your programs MIR-compliant.
The speaker at the conference in StrataConf is also author of Data Science Toolbox, a collection of shell tools for data science. But any GNU/Linux distribution will also give you all the tools you need to rock the MIR from your command line.
(*) Slightly made up story, but the point is not invalidated :)
Written on Jul 10 2014 | Comments »
- Intensive Metrics for Software Evolution (May 17 2013)
- Don't do empirical software engineering with Excel (Nov 23 2012)
- The impact of bias in bug-fix datasets for defects prediction (Apr 15 2012)
- Visiting UC Davis (Apr 02 2012)
- Popularity bias in bug datasets (Nov 01 2011)
- IJSODIT - Call for papers 2012 (Sep 29 2011)
- The interplay between businesses and open source (Sep 08 2011)
- Software and the game of life (Jul 29 2011)
- What's the distribution of software size? (Jul 20 2011)
- Software projects alzheimer: Julian Assange's lost contributions (Jul 07 2011)
- Practical Analyses of Software Engineering Data (Jun 15 2011)
- Empirical Software Engineering in Practice -- CFP 2011 (Jun 13 2011)
- Grafiti no es negocio -- Mi visión sobre las acampadas (May 25 2011)
- IJSODIT - Call for papers 2011 (Mar 29 2011)
- Mis impresiones sobre el Día Garum (Mar 05 2011)
- Nos vamos a Bilbao (Feb 15 2011)
- Reflexiones sobre el ciberpunk (Feb 03 2011)
- The dynamics of software evolution (Jan 24 2011)
- ¿Cómo he llegado al itinerario? (Jan 10 2011)
- ¡Hola itinerario! (Jan 04 2011)
- Debian finally shipping a free kernel (Dec 15 2010)
- Freenet, an anonymous and distributed network (Dec 11 2010)
- PyTwerp working again with Twitter (Dec 10 2010)
- "Making software" is out! (Nov 22 2010)
- Do featured articles get more visits in Wikipedia? (Nov 15 2010)
- What is the MSR challenge? (Oct 11 2010)
- IWESEP 2010 -- International Workshop on Empirical Software Engineering in Practice (Aug 23 2010)
- Learning by doing (Aug 10 2010)
- Data for Mining Software Repositories (Jun 25 2010)
- The eye of the tiger: agile methods vs. architecture (Jun 21 2010)
- Code as design. Or what's the point of Software Engineering? (Apr 06 2010)
- Hello Linkedin (Apr 02 2010)
- Special issue of the IJOSSP (Feb 23 2010)
- Where are you? (Feb 05 2010)
- New GPG key (Jan 27 2010)
- Under attack (Jan 19 2010)
- Hello world (Jan 18 2010)