Orestes Carracedo

Hardware

2015-02-28T00:00:00+00:00

Being a software developer is nice. Learning something new usually means downloading some SDK, running some new software or writting a different software. But still, the vast majority of written software runs on the same kinds of machines; screens. More often than not, you get to run your software on fancy touchscreens, interact with a mouse and keyboard. I like to break those boundaries and play with stuff that doesn't need a user to fullfill a purpose.

A few years ago, I bough an Arduino starter kit, and embarked on an the awesome journey to the Internet Of Things

This simple experiment doesn't look like much, but to me, it felt incredibly liberating. From then on, sensors, servos and DC motors have made learning really fun.

If you're looking for a fun hobby that involves programming, I cannot recommend this enough. I recently got a Fritzing Starter Kit and I coultn't be happier!

Learning

2015-02-15T00:00:00+00:00

I've been reviewing my progress over the past five years in Barcelona and Focus On Emotions. There's a ton of stuff that I've put into practice since I moved here. Most of this would be a bit overkill for simple projects, but I consider these practices are vital for any project involving more than one developer. All of these techniques were put to practice in personal projects first, and then brought into my regular job as Director of Software Development. Having a team to work together through the issues we found implementing these was really helpful.

What I've learned

Software Configuration Management

We checked every project into Version Control and applied a bunch of SCM related practices. We switched from Subversion to Git in 2011. There were many reasons, easier security handling, speed and Git's decentralized model being some of them.

We still used a golden repo where every other working copy was pushed to at the end of the day, or when we're kicking off an integration. That repo also pushed the changes to Bitbucket via a the Git post-receive hook. We've been using Bitbucket as a collaboration and visualization tool rather than a SCM storage service.

Along the way, we also adopted Semver as the sane guidelines for release versioning. Semver adoption is now almost the de-facto standard, at least for Open Source projects.

We also had a few different strategies to deal with branching. We opted to implement the wildly known git-flow and I doubt I would've ever need anything more complicated

The systems we worked on relied heavily on progressive enhancement. Both on the implementation and on the feature releasing cycle. We used a feature toggling approach for every new feature

For Open Source projects, GitHub is typically used as the SCM storage and collaboration platform.

Software Quality Assurance

Measuring Software Quality in metrics. I'm not talking about code coverage, but about cyclomatic complexity, deep of inheritance tree, object coupling... Most of the metrics were provided by PHP Depend, generated in our build process on Jenkins.

For Open Source projects, Code Climate provides a great service.

Testing

I spent my first years as a developer without writing a single test. The commitment to make code clean, understandable and reliable was only fulfilled when we managed to test every project we started. We did unit testing, end-to-end testing on some of the apps that relied heavily on the user interaction and acceptance testing using Behat for BDD.

Continuous Integration

We did CI on the development and master branches of our apps. We set up a local Jenkins server, using a computer monitor with loudspeakers. The monitor would feature a carousel of wall display lists of the jobs, alternating between the development and the stable branches. Different changes of the build states would trigger different sounds. The quick feedback from the CI system made us be more confident in our code than ever.

Open Source projects usually run their CI in Travis CI

DevOps

The set of practices meant to easy up and speed the deployment of new versions of our projects. We switched from manually created VMs in VirtualBox to Vagrant-managed VMs, provisioned by Puppet. Bringing up a new machine to test a new configuration or deploy a different environment for another app took now a couple of minutes, instead of hours (and multiple human errors).

We also wrote deployment automation tools using Apache ant, then moved to Phing then moved to Grunt.

How I learned

Most of this stuff I learned by reading a lot. I've tried to step up my game in these years and I managed to find more sources of knowledge than I could possibly manage.

Sources

My primary sources is always the Internet. Sites like Hacker News, Reddit and a carefully curated collection of blogs that I read via Feedly. Twitter is also fantastic, if you follow the active people in your community.

Podcasts are another great way to stay up to date. They're perfect for commuting.

Books are fundamental. No matter how insightful a blog post or podcast might be, they always reference written material. There are a lot of must reads in our field, so I started as early as I could.

Conferences and meetups are perfect for networking, speaking to other developers and share. I've tested the waters myself by giving a couple of talks in the past years and I must say that, even frightening, it's a lot of fun and you get to help out other developers.

Practice

Thoughtful, carefully prepared practice of everything you learn is critical. It's just not enough to read and vaguely retain the information. To truly understand, we must apply whatever we're learning.

Tell me and I forget, teach me and I may remember, involve me and I learn.

― Benjamin Franklin

Pet projects are a great way to practice. they work out even better if you collaborate with others. One of the potential pitfalls of pet projects is taking things too seriously. Remember, you're learning, getting better at something specific. The goal isn't for your pet project to be popular, grow into a company and get bought by Google. You're just learning, take it easy. Usually, it doesn't even matter if your pet project sees the light and gets released into the public. Keep in mind though that having a long list of unfinished ideas can be demoralizing. In time, I learned to downsize the complexity of my ideas and only released small things that I was ok with.

Empathy

Put yourself in the position of the rest of your team. Try to think like they think, to understand their problems and help them.

I've always liked to know as much as possible about the platform running my software. When I started as a freelance software developer, my websites and webapps where running in a shared hosting environment. The amount of problems and frustration made me realize how hard it is to be a good Systems Administrator. I moved all my clients into VMs. This meant I was now doing Systems Administration too, but it provided me with a ton of learning experiences.

The same goes for frontend development, mobile, etc...

What I still have to learn

Continuous deployment

I've never had the opportunity to work in a project when I could release as often as we made changes. I'm looking forward to doing so.

Test-Driven Development

It's easier said than done. TDD requires a certain level of work stability, self-discipline and focus I've just never been able to find. I'm making an effort to change this.

Domain-Driven Development

Such a huge topic. Digging into DDD feels like going down the rabbit hole. This paradigm could very well be as big as the Agile methodologies have been.

Mobility

Even though we worked in a few Mobile projects, all of them where part of the Digital Signage platform we built. I'd love to work on a project where the mobile client is the main focus.

High scalability

None of the projects I've worked have reached the numbers that high traffic systems support nowadays. Millions of daily active users. That's a whole new level, and I want to reach that.

Leaving Focus On Emotions

2015-01-31T00:00:00+00:00

Not that long ago I wrote about the beginning of a new chapter. Well, that was a short chapter. In hindsight, I guess I was trying to motivate myself and push through the merger. In the end, I wasn't able to make it. I don't see myself in the new project and I decided to leave before taking on a vital project that's coming up next.

I'm writing this sitting at the cafe in the OVD Asturias airport. Javier Morales and I have been delegating our tasks to the Software Development team based of Gijón. We're closing up the Software Development Department in Barcelona, everything will be moved up here.

It's been a rough two weeks. We had an awful weather and we barely did anything besides coming and going from the hotel to the office. The other team is absorbing all the knowledge pretty well and we're confident they'll be able to maintain our software for however long the company decides to keep it running.

In my time at Focus On Emotions, my team grew an shrunk as the circumstances provided. Overall, I'm very satisfied with our work here and I'd like to take a moment thank everyone who has been part of the team.

Virginie Faure worked with us at the very beginning of our product development. She wrote part of the core of our CMS and she moved in the blurry line that divides frontend and backend developers. She had a knack for interface and visual design and shaped the look and feel of our products.

Sergi Penya helped us quite a bit as a consultant. Most of our early interactivity projects where outsourced to him.

Valentí Gamez wasn't even 20 years old when he joined Focus On Emotions. He took care of the CMS maintenance role and helped us tremendously when migrating our website to Twig.

Xavier Rubio helped us as an external consultant. He's truly one of the most fearless developers I know. Through the years, Xavi helped us on electronics, backend, fronted and a myriad of other aspects of our software.

Dimas López came in to be the solid third dev on our team. We've been friends for many years but couldn't quite find the right opportunity to work together. In our time working together he absorbed all the knowledge like a sponge. It's been great seen him progress as fast and as far as he has now.

Raúl Jimenez consulted for us for almost two years. His work on our template engine made us one of the best solutions in the marked.

I'd like to give an special mention to Javier Morales. He's been the most important part of the Software Development team for quite a while now. He's evolved into a serious Senior Developer, capable of chewing anything you throw at him. Without him, Focus On Emotions would've never been as successful as it got to be.

Thank you guys sharing your time with me. I'm really grateful I had your help through this years.

Facebook Hacker Cup

2015-01-14T00:00:00+00:00

I've been entering Facebook's Hacker Cup for a few years now. Some years I've gotten past a couple of rounds, others I haven't done so well. Anyways, I really like participating and I decided to share my setup.

I use the same structure for every problem so I can be more efficient. Every problem:

Is in a directory named using the point value and the problem name, like 30 Balanced smileys.
Contains a readme file with the full description of the problem.
Contains an example directory with the input and output files provided in the problem description.
The data directory contains the generated input provided for the submission.
The generated directory contains the output generated for the submission.

The tight loop

I'm using the simplest quickest feedback loop I could come up with:

Run the program piping in the input from the example file and piping out the output to an output file.
Diff the generated output file against the expected output file.
Repeat

An example using php:

watch -n 1 "php solve.php < example/input.txt > output.txt && diff example/output.txt output.txt"

Using python:

watch -n 1 "python solve.py < example/input.txt > output.txt && diff example/output.txt output.txt"

I usually have this running in a session, and code in a different one. I like running the code very second and not relying on file watchers

What I often do wrong

This time I entered the qualifying round the last day. I ignored my calendar events for the day when I shouldn't. As a result, I entered the round feeling in a hurry and didn't concentrate as much as I should've.

In past editions I've overlooked the constraints and tested the code using simple scenarios. The problem comes when the generated input hits the constraint limits and my code is not optimized at all, taking a lot of time to perform the calculations and making me fail the problem.

Another mistake I made was preparing only one problem. Chances are I'm going to be fail to think about every scenario and fail the problem. Solving (or at least trying to) all the round's problems should always be the way to participate.

Links:

orestes/facebook-hacker-cup on GitHub.

Shortcuts

2014-12-31T00:00:00+00:00

I love shortcuts. Specifically, keyboard shortcuts. Quick keystrokes that invoke commands and menu options. I couldn't live without them. But that's me. It seems normal that people don't use them at all save for CTRL+C and CTRL+V.

One of the main goals as developers is automating repetitive and error-prone tasks. There's very few things that can get as repetitive as clicking OK or Cancel on dialogs, checking boxes or navigating between form fields. And yet, very few people use Tab or Shift+Tab to navigate between form fields, Space to check checkboxes and Enter or Escape to accept o dismiss dialogs. I can totally understand that the average computer user won't get used to this, but I can't respect a developer that doesn't know his tools. And that doesn't mean you have to be an Emacs guru, but regardless of your tool of choice, you better show me your skills when I'm interviewing you.

That's what this is all about; mastering your tools. I don't care that much about the particular tool as long as you prove that you know it inside out. I'm not the only one who thinks on this vein. I recently read the best IDE in the world by Nichas Bize and I found myself bobbing my head in agreement all along.

Links:

The Best IDE in the World by Nicolas Bize.

A new chapter

2014-11-30T00:00:00+00:00

In 2010 I had been working on public administration projects for two years. For me Tenerife was a great place to live for a while, but not to stay forever, let alone to stay for work. There simply was no tech job market. When I got fed up, I decided to move and leave the island (there's a LOST pun in here somewhere) looking for something better. I teamed up with a coworker, we quit together and moved to Barcelona.

I was amazed by the quality and quantity of job offers there where. I chose to join Focus On Emotions, a promising Digital Signage company. I knew nothing about this sector but it looked fascinating. The first thing that comes to my mind when I think of Times Square in NY or Shibuya in Tokyo is that look that reminds me of Blade Runner.

CC Photo by Héctor García. Shibuya from Hikarie on Flickr

It's the mesmerizing collection of ad displays covering the buildings. With this expectations in mind it's fair to say I was a little excited about getting to work with that kind of tech. One of the drawbacks of being a backend software developer is that your work doesn't get noticed by the general population. I was eager to work on something I could walk by, point to and say, "Hey, see that cool multimedia 6x4 videowall over there? Yeah, that's running software I wrote".

CC Photo by Javier Gutierrez Acedo Times Square2 on Flickr

When I started working there there was no Software Development department, almost everything was being outsourced. We used Digital Signage software licensed from our competitors. I was tasked with the creation of the Software Development team, it was going to be the challenge I was looking for. In the following years, I devoted my heart and soul to my role. I did everything from candidate screening, to training to architecture design. We managed to recover a few projects that were on the verge of failure. We developed our own Digital Signage player, our own CMS and CDN platform, adding features that none of our competitors had, integrating with third party services and steadily delivering project after project. Our department became the backbone of the company, we were able to secure bigger projects and clients and keep growing technologically.

Almost five years, 85+ repos, 6 team mates and a whole lot of projects later, I feel really proud of our team. We've worked on so many different things it doesn't compare to any other job I've had. We've done electronics integration, developed the first Digital Signage platform based on Android and we're now finishing the Digital Signage integration for ThyssenKrupp. I never thought I would see my software running inside an elevator! Thorough this years we've managed to be up-to-date as much as we could. We got some certifications, we attended a whole lot of conferences, meetups and user group talks, we even got our feet wet and presented some of our projects to our peers. It was a never-ending learning experience that we're committed to keep going.

In June 2014 we were bought by one of our competitors, Altabox. Together we're a bigger company, a bigger team which can tackle bigger problems and keep growing internationally. I feel like the hard work we've put into our software paid off. We now we are bigger, we have more resources, more interesting projects and a longer road ahead of us.

Company culture is one of those things most of the small companies can't offer. Having to companies merge into one is no easy task, so they flew us from Barcelona to Gijón for a two-day corporate retreat. Meeting our new co-workers in an informal setting was a nice experience. You get to know the people you work with in a more personal level. You don't see positions and responsibilities, you see new friends.

After a couple of hours of corporate presentations we had lunch together. We mixed a bit, had some good laughs, there was some impromptu performance by one of the most artistic team members, Dimas, and everyone seemed to be enjoying themselves. After lunch, we toured Altabox's facilities. The first thing that hit me when we were going to the Gijón office is that we now took up a whole bus. That's the first time I thought "wow, this is really happening, we're this big now". Altabox is located in an impressive museum at "Laboral Centro de Arte y de Creación Industrial" and getting to the office is pretty much like going through a labyrinth. The upside is that you get a tour of the museum and get to look a newer cool stuff every time the exhibition changes. When we got to the offices we joked about the cable mess and how it felt like we were already home. The office was a nice open concept but what stuck with me was this huge black chalkboard spanning an entire wall. Oh, how badly I wish to have something like that in Barcelona...

No corporate retreat would be done without at least one team building exercise so that's where we were taken next. When we stepped out of the bus into a TV studio I was baffled. Turns out the exercise was to make a movie/TV segment. This was an actual TV set so it was fun to play with the cameras, the boom mic and getting to sit in the interview sofa. We split up in two groups and had a blast acting up roles and recording the whole thing. We had a tour of the sound control and editing rooms where they explained a bit how the modern TV world worked. It was really interesting. The whole exercise was was really fun and I feel that we got along pretty well.

The day ended after having dinner together and partying until late. Our hosts where really nice, took us to a few different spots and we had a lot of fun together. Flying back to Barcelona the next day I was pretty happy about the future of the company.

We're now ~35 people, we manage thousands of displays across tens of countries and we're only getting bigger. This is the start of a new chapter. It's our job to start building up this new company. The Software Development team just doubled its numbers but we still have to overcome the difficulties of remote collaboration. There's a ton of work ahead, a long list of challenging projects and deadlines but now there's more of us, and we're ready :)

Links:

Controlling a USB-RLY02 relay module over USB using C#, JavaScript and ActiveX

2013-07-21T00:00:00+00:00

It was 2010 when we got some projects at Focus On Emotions from Ikea. Among the challenging stuff we did for them there was a project for automating the process of the users registering for a credit card. The final product was a digital user stall/kiosk with an interactive touch screen a physical keyboard and mouse. This project needed a couple of tricky features: ID verification and bank authorization.

This was not our first rodeo and we had another public kiosk/stall project for the city hall, Ajuntament de Barcelona which allow citizens to do paperwork. They were challenging because we had to integrate lots of different providers, but we didn't manage any banking data so this was new to us. These projects had been running smoothly for years and we've got some recognition from them.

A couple of weeks after the project's launch we had gotten many reports of users being disoriented when following the process. One of the steps required the users to physically place their ID form on a small flatbed scanner for validation. Even though the physical space was an obvious empty box the users didn't realise that was where they were supposed to place their ID.

The client asked us to modify the kiosk structure, add a LED stripe around the empty box and have it blink when the users got to the ID validation step. We had to give it a little thought before coming up with a solution because we had a tricky problem: hardware access was impossible. The whole application was written in Java, HTML and JavaScript,and it ran as a served web app inside a secured environment using SiteKiosk. This was great for pushing software changes to the multiple kiosks installed for the project as well as for interacting with the bank's backoffice services in a secured environment (server-side). The manufacturer for the ID scanner had provided the dev team with an API that used ActiveX and JavaScript to control their hardware, so we followed that idea: we had to develop our own ActiveX control to activate the LED stripe whenever we needed to.

We bought a simple relay board with an USB interface and started working on it. This relay board was great because it had two different relays that you could control independently. Each relay had a tiny onboard LED indicating its state. You can find it on RobotShop, here.

I got a hold of the controller's specification [mirror] and wrote a simple program to control it over USB by sending the byte-encoded messages for each action (open/close relay 1/2). It consisted of a minimal Windows Forms interface with a few buttons to open/close the USB port and switching on/off the relays. When I was sure I could make it work, I wrote a small function library and compiled it as an ActiveX:
csc /t:library USBLEDControllerLib.cs
To make it available for Internet Explorer, the DLL had to be registered:
regasm /tlb /codebase USBLEDControllerLib.dll
Both regasm and csc are provided by .NET Framework 2. in my case, It was already installed on %WINDIR%\Microsoft.NET\Framework

To invoke the ActiveX control we use the full classname, including namespace.

var controller = new ActiveXObject("FOE.USBLEDControllerLib");
var version = controller.getFirmwareVersion();
console.log('Running FOE USB LED Controller version ' + version);

The simple ActiveX control would trigger a security warning on IE. We suppressed this warning by implementing a few visible COM methods flagged as [Serializable, ComVisible(true)] which come from the IObjectSafety interface. This told IE it could trust our library.

The controller for the board had a limited set of functions so we had to extend them for our project. I added a couple of threaded functions to start/stop blinking the LEDs synchronously, stopping/starting only one of them and have the other synchronize on start, etc... Even though we had very little time and a lot of pressure I think it was a fun project. You can see the PoC in the video below. You click a button on a webpage and a LED lights up. Neat! I love the clicking sound from the relays, so mechanical :D

Links:

Procedures and services stalls at BCN.cat
Safe Initialization and Scripting for ActiveX Controls on MSDN.
Public Sector clients at Focus On Emotions
Devantech 2 Channel USB Relay at RobotShop.
USB-RLY02 module specification at RobotShop. [mirror]

Migrating from Wordpress to Jekyll on GitHub Pages

2013-06-09T00:00:00+00:00

Besides my writing skills, my problem with blogging was the software I was using, Wordpress. I found it slow, heavy and often insecure. I didn’t want my server exploding whenever I got a traffic spike, I didn’t want upgrading my WP modules and being worried about security issues. It was kind of hard to get it to look the way I wanted it. I wrote a custom theme but I wasn’t really satisfied with it, so I bought a one which looked cool, but I still wasn’t happy with my blog because it wasn’t “mine”.

I wanted a static blog website that I could code and style the way I wanted, without restrictions. I wouldn’t have to worry about security since it would be static and would have no user input, search or comment features. I didn’t want to give up comments so I checked Disqus, whichs a really good commenting platform that you can embed anywhere without having to worry about security or performance issues. Disqus is a seamless iframe whith a lot of clever programming inside. Ben Vinegar, gave a great talk about it in 2012: Seamless iframes: The future, today!.

Regarding the traffic spikes and server resources, I decided I’d move the blog out of my lab hosting (which is a tiny virtual machine) into somewhere that could serve static sites and I only had to worry about bandwith costs,

I started researching about scaffolding tools and generators for static websites. I had used stuff like yeoman that worked reat for getting something started quickly, but it was more aimed at apps than static websites and I’d still have to do a lot of the work.

Then I found about GitHub Pages and Jekyll, and they turned out to be the perfect solution for me. Jekyll is a blog-aware static website generator written in Ruby by Tom Preston-Werner. It’s easy to get started with and powerful enough to let you add your own plugins and teach it new tricks. GitHub Pages allows you to serve static content from your GitHub repositories without any setup

The pros Jekyll on GitHub Pages

It’s already blog-aware, so it has a notion of posts, categories, tags and a timeline.
I can version my posts and contents using a CVS I love (git)
I can easily share the source code for my blog
I don’t have to worry about hosting
I can still use any domain name I own
It provides higher geek factor than having a WP blog

The cons

GitHub crashes every once in a while and maybe GH Pages comes down with it

Working with GitHub Pages

GitHub Pages are divided into user pages and project pages. The only thing you have to do is create a gh-pages branch on your repository. Whatever you push to the branch will be served on your project page at http://username.github.com/repository-name. If you push a Jekyll site, GitHub Pages will actually build the site for you and serve that instead of the Jekyll source.

Working with Jekyll

You create a new site running jekyll new PATH which creates a bare minimum site config and layouts.

To create the extra tag and category index, as well as the archived month pages, I had to extend the same classes: Jekyll::Page and Jekyll:Generator. The method is pretty straightforward:

Create a class that inherits from Jekyll:Page
In the page class, implement the initialise method
In the initialise method, call self.process(@name) and self.read_yaml to get the contents of the layout
Add to the site.data Hash any data you want to expose to the page
Create a class that inherits from Jekyll:Generator
Implement the generate(site) method which adds instances of the custom page to the site.pages Array

I generated the monthly archive by iterating over the site.posts Array and analysing the dates. To generate the sidebar menu that displays the year/month list I needed to have an index to iterate over, so I coded my plugin archive_helper. What I did was:

Inherit from Jekyll::Site,
Made an alias of the original site_payload
In my site_payload method, called the original site_payload and get the returned data.
Added to site.data Hash the indexes created from the posts’ dates.

The plugins to generate the tag and a category pages were already provided in the Jekyll plugin docs so I didn’t need to do any extra work.

You can get the source code for my plugins and all of this blog here

Deploying the site

The problem I had with my plugins is that GitHub pages builds the Jekyll sites using the --safe switch, which disables them. The alternative is to push your source code to the master branch and your generated site files to the gh-pages branch. I didn’t want to do it manually every time I updated the source, so I wrote a little post-commit hook that generates the site, wipes the gh-pages branch and pushes the freshly generated site to the gh-pages branch.

Using a custom domain name

Everything gets served from http://username.github.com/repository-name. Having a good grasp of the HTTP protocol is crucial for a web developer, and I think we should also know at least a little about the DNS protocol. I wanted to host my blog under blog.orestes.io, so I got to my DNS panel on my domain registrar and added a new CNAME DNS entry for orestes.io with the name was blog and the value orestes.github.com. A CNAME is a Canonical Name entry, which tells DNS clients asking where blog.orestes.io is, to ask instead for orestes.github.io.

Let’s check what’s going on with my domain name using nslookup.

$ nslookup blog.orestes.io
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
blog.orestes.io	canonical name = orestes.github.io.
orestes.github.io	canonical name = github.map.fastly.net.
Name:	github.map.fastly.net
Address: 103.245.223.196

On the output above you can see how everything is being redirected to github.map.fastly.net

When you finally get to the HTTP server behind github.map.fastly.net, it checks the HTTP 1.1 “Host” header, which is sent by the browser and will contain the value blog.orestes.io. Then the GH Pages takes a look under the user’s projects and their /CNAME files to check if any of this projects is assigned to this domain. If there is, you get the static site, if there isn’t, a 404 error.

Links:

Source code.
Jekyll docs.
GitHub Pages help.
“Blogging like a Hacker” by Tom Preston-Werner.

Breaking the 1000ms Time to Glass Mobile Barrier

2013-04-10T00:00:00+00:00

A great talk by Ilya Grigorik.

Links:

Interview with Ilya Grigorik on Applines
Breaking the 1000ms Time to Glass Mobile Barrier on YouTube.

What is "Niantic Project"?

2012-12-10T00:00:00+00:00

This was posted about a month after the launch of Ingress, an Augmented Reality game by Google. In the beginning you could only be invited by someone working on the game, so we had to post ingress stories, artwork, articles, whatever we could to get attention from them and receive an invitation to play. Today is much easier to get invited, you can just go to ingress.com and request an invitation. It's really fun!

Ok, I have to tell you about this. I was looking for information about "Ingress" which is some kind of game a few people are playing but nobody seems to know how to get access to. I was browsing around and found out about something called "Niantic Project". Apparently there's something big going on and only a handful of people and aware of it, the ones playing Ingress.

I found a few cool pictures while googling around and I wanted to save some for later, but I accidentally saved this one as a .html file and that's when things got weird.

Try and do it yourself. Save this image to your local disk, and rename it to from .jpg to .html. When you open it in your browser, it will look almost the same, but you'll notice that your browser's background is now black, and the image has a weird green border around it, something it didn't have before. If you move your mouse over the image, you're going to find a mysterious text that leads to a strange website. I don't know who exactly created that webpage, but there's a ton of info on there.

Why whould somedy hide something inside an image?
What are they hiding from us?
What is "Niantic Project"?

Links:

GOTO Aarhus 2012 playlist

2012-12-06T00:00:00+00:00

Update july 2013: Jez's talk has been deleted :(

The playlist rom the recent GOTO Aarhus 2012 has been published on YouTube.

Jez Humble's "Implementing Continuous Delivery" where he talks about the organisational problems, mistakes and misconceptions that come up when trying to implement Continuous Delivery has been one of my favourites.

Link: GOTO Aarhus 2012 playlist on YouTube (79 videos, 53 hours)

HTML5DevConf 2012 playlist

2012-11-21T00:00:00+00:00

Ben Vinegar's talk Seamless iFrames: The Future, Today! was very interesting.

This was a WordPress blog until I switched to Jekyll and started using Disqus for the comments and I must say I love it.

Link: HTML5DevConf 2012 playlist on YouTube (60 videos, 30 hours).
Via: HTML5 Weekly

Why programmers work at night: the book

2012-11-17T00:00:00+00:00

Programmer Swizec Teller and author of the (now) famous blog post "Why programmers work at night" has started a project on Leanpub to publish a book about programmers.

[...] In December 2011 I wrote down a bunch of assumptions about Why programmers work at night (link) in a blogpost. I wrote it because I got tired of being called a lazy slob for waking up at 11am every day. After 4000 tweets, 10000 likes and many emails I didn't feel alone anymore. The most surprising feedback were emails along the lines of "Oh man! I finally understand my husband, thanks so much for writing this!". And it is because of those that I have finally decided to write a short ebook. In the book I'm going to:

Show fellow night-time programmers (and others!) that they are not alone

Give practical tips on living with your friendly neighborhood programmer

Support my original hypotheses by interviewing cool programmers

Explore the modern trend of super early wakeruppers who approach the night time from the other end

So if you're a programmer that feels missunderstood on your late nights of happy coding, maybe this book will be an ideal gift for your roomies, girlfriend, boyfriend, parents or even for your boss.

Link: Why programmers work at night: the book

Petr Mitrichev

2012-11-16T00:00:00+00:00

I first learned about Petr Mitrichev the past year when he won 2011's Facebook Hacker Cup. He's a Google developer leading the current competitive programming challenges. He also keeps an interesting blog at petr-mitrichev.blogspot.com where he talks about algorithms and sometimes challenges his readers with some problems.

MIT's Technology Review has a nice introductory article about him.

I also found some interesting reading material if you're into competitive programming. Codeforces has a great post about Sao Paulo Training Camp 2010 containing his solutions to problems and some video explanations.

Update March 2013: He came up on top at 2013's Facebook Hacker Cup as well. This is guy is amazing :)

Links:

NFC Bootcamp Barcelona 2012

2012-11-14T00:00:00+00:00

The NFC Bootcamp Barcelona 2012 was held as part of the Smart City Expo World Congress 2012 at the Fira Gran Via Convention Center in Barcelona. We had some problems when trying to get our accreditations at the entrance but with a little help from the organisation we managed to finally get inside.

We met Robert Sabella from OTA Training and we chatted for a bit while we waited for others to arrive. Rob started the day by introducing NFC and the work the NFC Bootcamp has being doing for the past year.

Bastien Latge from INSIDE Secure followed up with a more in depth talk about the key players in an NFC Ecosystem and underlined some of the most common problems and situations companies deploying NFC solutions encounter the most. He talked about the NFC parts, specially the Secure Element and the different implementations and security measures implemented in them. He also talked briefly about the hardware which provides NFC capabilities for mobile phones without built-in NFC tech.

Just before lunch, we met Stéphane Doutriaux from Poken. He made a brief introduction about Poken with a video. Afterwards we all got our own pokens and did a little tour of the reception area and the schedule wall poster, poking along the way and getting comfortable with the devices.

After lunch, Gloria Lozano from BCN Touch gave her talk, focusing on use cases and their projects from the last past years.

Then Stéphane came back to talk a bit more about the marketing and user experience side of NFC and how he thinks we should put the most of our efforts in providing some value rather than some technology, and use NFC as a means and not as a goal.

At the beginning of day 2, we got a USB NFC reader and different cards with different NFC chips in them and Bastien finished his talk about the players in the NFC environment.

Then we met Fernando Cejas, a mobile developer based in Barcelona, working for Flomio. He's also de organiser of the Google Developers Group Barcelona. His talk was going to be more focused on de technical/developer side of NFC but due to the majority of the assistants being not so technical that part was skipped. Bummer.

Before lunch, we went for a walk around the Smart City Expo and Fernando was captured by an evil robot. After we rescued him, Fernando gave a more technical explanation of the NFC components, the different NDEF well known formats and the read/writing permissions. He also talked about the idea of "cloud tags", flomio, the FloJack to provide NFC for iphone/ipad devices and other solution prototypes they had researched using other tech such as the Raspberry Pi and the GuruPlug

Then Stéphane came back and we participated in a workshop with Poken and their partner tools. We created a campaign and linked a Poken Tag using the NFC Reader/Writer. We also learned a bit more about the technology used in Poken. The Poken tags use the same technology as the regular Pokens. They use a Swatch licensed chip with added NFC capabilities and a full USB stack,powered by a 9 volt battery that lasts about two years. Everything is encased in silicon so its fairly resistant, and of course, it's sticky. Poken Tags have to be activated using an NFC writer and power themselves off when they are stacked or they detect too much inference to not drain the battery.

We all got an NFC Bootcamp completion certificate on behalf of OTA Training and the AENFC and we took some pictures. It was a great experience and I'm sure both speakers and attendees will keep in touch with each other.

Links:

Understanding NFC NDEF messages at Nokia Developer
Poken - Collect People, Places and Things on YouTUbe

Let Silex Wrap Your Legacy PHP Application

2012-07-01T00:00:00+00:00

PHP + Symfony developer Matthias Noback has written a really nice article about the use of Silex on outdated PHP projects. If you've been looking forward to migrate/redo some of your old projects using Symfony components, this may be worth reading.

Link: Let Silex Wrap Your Legacy PHP Application (and add Twig for templating)

Fluent 2012 playlist

2012-06-06T00:00:00+00:00

JavaScript development workflow of 2013 by Paul Irish was amazing!

Link: Fluent 2012 playlist on YouTube (58 videos, 5 hours).

Learning to love JavaScript

2012-04-30T00:00:00+00:00

I really liked Learning to love JavaScript by Alex Russell at Google IO 2011.

Link: Google I/O 2011: Learning to Love JavaScript on YouTube.

Why programmers work at night

2011-12-18T00:00:00+00:00

I just read an excelent article by Swizec Teller about the reasons some programmers do their best work late at night.

I couldn't agree more with the author. The past year I stayed late at the office a lot of times doing a lot of good work. This year not so much because my girlfriend moved in with me, so I've gotten some rest from that but I kind of miss it too. When we were working on Aura, we would work until very late and wake up for lunch almost every day.

Link: Why programmers work at night