Hello! I'm David Francisco.
I live in Coimbra, Portugal.
I'm an Informatics Engineer, passionate about the web.
Based on Catching Elephant, a theme by Andy Taylor. Icons by IconDock, Komodo Media and Y. Kamiyamane.
I really like Git. For more than a year now, I can easily do everything I need with it. Still, the impression I kept having was that my processes could be hugely improved in several ways. I then began to refine those processes and, as they became more complex, I started adding aliases for various operations. Soon after I reached a point where it made more sense to follow the workflow by Vincent Driessen. I went back to try the gitflow command-line app and started to enforce it on a personal project.
So far everything’s going well. I decided to pick up this interesting post by Harry (from csswizardry) and tailor it to gitflow (there are several portions that are copy-pasted from there, so the credit goes to him). If git workflows is a topic that interests you, follow the link: gist.github.com/5072619
As developers, we tend to be on the command line a lot, whether editing code, running a build, or testing new tools. Given that, it’s nice to be able to manage our work without leaving the command line. — David Copeland
k▥ (pronounced kood) is a command-line tool for task boards. It’s collaborative and works offline. All data and settings are stored in text files. The application uses Git to handle conflicts and keep track of changes.
It’s a pet project, not intended for real use. The idea was to use Git as a database and take advantage of some of its features (such as conflict-resolution and branching) and distributed nature.
You can create several boards. For instance, you may want to set up a board for your side-project. The board is saved as a Git branch that you can keep on your project’s Git repository. Each board has lists (you may think of them as columns). Your board could have lists such as “Backlog”, “In Progress” and “Live”. Each list holds cards. A card may have a description and labels (such as “User Story”, “Improvement” and “Bug”).
The application is written in Ruby and was built on the shoulders of Grit, Thor, ToyStore, and Ronn. The initial implementation is available on github.
This year I once again attended to SAPO Codebits, probably the greatest tech conf / hackathon in Portugal. This was our 48h-project, number 404. It received 191 favorable votes against 14 non-favorable votes.
Here’s the problem we were trying to solve:
All attendees love the opening keynote. So much that when it ends, there is a rush to the main area to take over tables. And then you are meters apart from your other group members, each on a table with unknown nerds all around. Our approach is to ask attendees who they want to be sat next to. Groups of up to 6 are formed, and before the big day, Celso runs a script that generates the optimal distribution of attendees per table that sits group members together. Now take this idea from codebits to wedding choirs, cinema, buses, hostels, planes, trains, etc… You will never be alone with strangers anymore.
<note>No Flash was used in the making of this project</note>
A little video I recorded some months ago. Pomada was a simple web app I started to play with the new features of chrome packaged apps and to try out the pomodoro technique.
You need absolute solid lengths of time to think.
A not-so-explanatory short video about my internship at IPN.
Some contents from my internship at the Instituto Pedro Nunes.
The need to have diagrams to explain and describe ideas is common in the software development area. Whether in draft documents, or in formal presentations, I like my diagrams to be visually simple, without distractive elements, and made in a way that can be reused in other formats (including printed documents) without losing quality.
Nowadays, as the size of client-side code increases, web developers have become more and more obsessed with performance. Even on personal webpages and non-profit projects, the use of minification techniques is becoming the norm. Yet, in my opinion, some of those techniques, mainly minification and file combination, are bad for developers. The “view source” browser option and other inspection tools have always been an important part of learning and discover, for both front-end developers and web designers. Therefore, I think that, along with combined and minified JavaScript files and stylesheets, uncompressed versions of those assets should be made easily available too, whenever possible. We learn from others and so we shouldn’t prevent our fellow developers from learning from what we do (even when being a newbie). Recently I’ve been thinking of ways to take advantage of those optimization techniques while simultaneously ensuring the developer-friendliness of the website.
I started a side project last weekend and today I’ve managed to get it done.
It’s just a proof of concept ◕ ‿ ◕
