Jorge Maroto

Analizando los datos de las Oposiciones a Maestros 2022, Comunidad Valenciana

Mon, 18 Jul 2022 17:55:30 GMT

Hace unos días que han terminado las oposiciones para el cuerpo de maestros en la Comunidad Valenciana, y me picaba la curiosidad de cómo habían ido en función de los tribunales y/o provincias.

Antes de nada, decir que toda esta información es pública en la web de la Conselleria de Educación, Cultura y Deporte de la Generalitat Valenciana (link directo), por si alguien quiere acceso a la fuente original.

Pantallazo de la web con las actas por especialidad

Tengo intención de escribir otro blogpost algo más técnico de cómo he conseguido agregar la información – hay cerca de 4000 archivos PDF, para las 7 especialidades y cada uno de los tribunales en las tres provincias (Alicante, Castellón y Valencia)–, pero en éste me quería centrar en comentar los propios datos y dejarlos en formato Google Sheet al final del artículo por si alguien más quiere trastear con ellos.

Análisis de los datos

Una vez con todos los datos juntos, he realizado algunas agregaciones que me parecieron interesantes para representar en las imágenes que dejo más abajo.

Datos curiosos

💃 Con unas 50 personas por tribunal, las especialidades más demandadas fueron Infantil (147 tribunales y 7376 presentados) y Primaria (135 tribunales y 6772 presentados).
🎼 La menos demandada fue la de Música, con 497 personas repartidas en 11 tribunales.
👌 19 personas en Infantil y 7 en Primaria han conseguido sacar un 🥇 10 en ambas partes. ¡Enhorabuena!
🔁 El tribunal V60 de Primaria es en el que más notas se modificaron, con 19 cambios en el tema, 11 en el caso práctico y 1 en la programación, aunque sólo 5 de estas personas pasaron de no poder presentarse a la segunda prueba al sí poder hacerlo 🌺.

Resumen 10 / 0

A continuación muestro una tabla agrupando a las especialidades por número de 10 en todo (🥇), y 0 en todo (👎).

Aprobados por tribunal

En cuanto al número de aprobados por tribunal, lo he separado teniendo en cuenta el conseguir superar cada una de las pruebas, para al menos llegar a presentar la programación, o lo que es lo mismo:

más de 1,25 en el tema.
más de 1,25 en caso práctico.
con lo anterior se superaría la prueba 1 con más de un 2,5.
más de un 5 en la programación o prueba 2.

Modificaciones en las calificaciones

Las siguientes gráficas representan el número de calificaciones que fueron modificadas del listado provisional al definitivo (probablemente tras una reclamación) para cada una de las partes de la prueba.

Resulta bastante curioso ver el tribunal V60 para Educación Primaria, donde en el tema hubo 19 modificaciones, en el caso práctico 11 y por último 1 modificación en la prueba 2.

Enlaces de interés

Por último, comparto a continuación la web con las actas separadas por especialidad y tribunal, donde hay acceso a cada uno de los PDFs con las calificaciones, así como el Google Sheet que he generado con toda la información agregada.

Actas de los tribunales (ceice.gva.es).
Google Sheet con la información agregada.

Monitoring a Raspberry Pi: Grafana with Prometheus

Sun, 07 Jun 2020 20:30:00 GMT

This is the second part of an article about how to monitor a Raspberry Pi using Prometheus and node_explorer. The first part is available here.

In this part, we'll install Grafana with Dokku in our Digital Ocean droplet (5$/month).

4. Install Grafana in Dokku

As we did with Prometheus in the first part, we'll create the Dokku application and allow Grafana to write to the data folder.

# Create the Dokku application
dokku apps:create grafana

# Create the directory where we'll store the prometheus data
mkdir -p /var/lib/dokku/data/storage/grafana/

# The Grafana container uses the user id `472`, so we change the permissions to do that directory writable
# Related: https://github.com/grafana/grafana/blob/293ecbdd4fe1e0b636eb7d0a7e0184ace0f20a80/Dockerfile#L39-L40
sudo chown -R 472:472 /var/lib/dokku/data/storage/grafana/

Locally, we'll create the git repository and add the files needed:

# Initialize the repository
git init

# Add a new remote called `dokku` with our Dokku host
git remote add dokku [email protected]:grafana

Dockerfile (using Grafana as a base, we'll include the specific configuration for nginx)
nginx.conf.sigil (just to increase the size limit for POST requests from Grafana, for example to take snapshots of a dashboard).
app.json (optional, but I'm using the dokku-require plugin, this file configures the mounted volumes).

FROM grafana/grafana:7.0.3

COPY ./nginx.conf.sigil .

Dockerfile

...
...

	client_max_body_size 250m;

...
...

nginx.conf.sigil

{
  "dokku": {
    "volumes": [
      {
        "host": "/var/lib/dokku/data/storage/grafana/data",
        "app": "/var/lib/grafana",
        "phases": "run,deploy"
      }
    ]
  }
}

app.json

As we're using a Dockerfile Deployment, we're adding this sigil template to our application WORKDIR. It's a copy from the default template, just adding the client_max_body_size config, which allows to POST bigger requests, for example when we'll export a Grafana snapshot.

After pushing to our Dokku repository, we'll be able to connect using the default domain and port, but we can set those up:

dokku domains:add grafana grafana.mydomain.com
dokku proxy:ports-set grafana http:80:3000
dokku letsencrypt grafana

You can now open grafana.mydomain.com in your browser and enter the default user: admin / admin.

5. Connecting Grafana to Prometheus

Grafana and Prometheus are working in two different containers, so if we want Grafana to read the data from Prometheus, we have to connect both networks.

Using Dokku, it's easy to create a new network, and use it in both containers:

dokku network:create grafana-prometheus
dokku network:set prometheus attach-post-create grafana-prometheus
dokku network:set grafana attach-post-create grafana-prometheus

# After that, we could see a report of the networks per application
dokku@ubuntu-dokku:~$ dokku network:report prometheus
=====> prometheus network information
       Network attach post create:    grafana-prometheus
       Network attach post deploy:
       Network bind all interfaces:   false
       Network web listeners:         172.17.0.7:9090
       
# But we could use also the name of the container, for example: http://prometheus.web.1:9090

With this URL, we can create a new datasource from our Grafana website: https://grafana.mydomain.com/datasources, adding the URL of Prometheus.

After that, we can start running some queries against Prometheus, there are a bunch of examples on their website.

6. Importing a node_exporter dashboard

An interesting feature of Grafana is the ability to import dashboards; they even have a repository with lots of them.

Thanks to that, we can find a Node Exporter Full dashboard, which we can import just using the ID (1860) in https://grafana.mydomain.com/dashboard/import, and we'll have a dashboard like the following.

Recap

In this part, we've seen how to install Grafana in Dokku, and also how to connect it to the Prometheus installed in the first part of this article to use as a data source.

As you've seen, this is a cheap way to monitor a server, from a Raspberry Pi at home to a more professional setup at your company, because you can even define alerts to get notified when something goes wrong.

References

Grafana: Node Exporter Dashboard
Github: raspberry_exporter

Monitoring a Raspberry Pi with Prometheus & node_exporter in Dokku

Sun, 07 Jun 2020 20:00:00 GMT

In recent weeks, I've been having some issues with my Raspberry Pi, which unexpectedly stopped working after a few days, so I asked a question on Twitter, and the following stack was one of the proposals.

Desde hace unos días se me está quedando frita la raspberry donde tengo montado #homeAssistant, y no se muy bien el por qué.

De momento estoy usando @StatusCakeTeam para enterarme, pero no veo un patrón, así que voy a empezar a monitorizar tb los clásicos de CPU/Mem
— Jorge (en fase 1) (@patoroco) June 6, 2020

Prometheus is one of the most popular options when you think about a monitoring solution (time series based, alerting, etc), and one of its sub-projects is node_exporter, which shows a list of metrics that will be consumed by Prometheus.

Dokku is The smallest PaaS implementation you've ever seen, and I've blogged about it several times because I'm using it for all my personal projects hosted on the smallest droplet at Digital Ocean (5$/month).

I've divided this article into two posts, and these are all the parts:

Export the metrics from the Raspberry Pi using node_exporter.
Make the metrics accessible from the internet (as we'll run Prometheus on a DigitalOcean droplet).
Install Prometheus in dokku.
Install Grafana in dokku.
Connect all the pieces.
Importing a node_exporter dashboard.

1. Exporting the metrics

node_exporter is a small application that exposes several metrics in a format that Prometheus is able to pull.
The installation is straightforward and consists of downloading the package from the releases tab in Github, and running it (these commands are run on your RPi).

# Download the package
wget https://github.com/prometheus/node_exporter/releases/download/v1.0.0/node_exporter-1.0.0.linux-armv7.tar.gz

# Extract the package
sudo tar -xvf node_exporter-1.0.0.linux-armv7.tar.gz -C /usr/local/bin/ --strip-components=1

# Run the node_exporter
node_exporter

In my case, as I have a Raspberry Pi 3, I've downloaded the ARMv7 release from the list.

Once you run the command, you can visit http://<raspberry_IP>:9100/, and click the metrics button; in my case it links to http://192.168.0.166:9100/metrics.

# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 9.0365e-05
go_gc_duration_seconds{quantile="0.25"} 0.000183073
go_gc_duration_seconds{quantile="0.5"} 0.000413749
go_gc_duration_seconds{quantile="0.75"} 0.0005413
go_gc_duration_seconds{quantile="1"} 0.012291414
go_gc_duration_seconds_sum 2.396249156
go_gc_duration_seconds_count 4209
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 10
# HELP go_info Information about the Go environment.
# TYPE go_info gauge
go_info{version="go1.14.3"} 1
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 3.897568e+06

...
...

These are the first lines that node_exporter includes

You don't want to run this command manually every time your Raspberry Pi restarts, so you can add an entry to your crontab:

crontab -e

# Add the following line to your crontab and save the file
@reboot /usr/local/bin/node_exporter

You can reboot your RPi and check that it starts automatically as expected

2. Making node_exporter accessible from the Internet

As our Prometheus will be hosted on an external server (Digital Ocean in my case), we have to make our RPi accessible from the internet.

How to do that depends on your router, so I'm going to share a screenshot of my router's configuration, where you only need to set up the port to be mapped to the RPi. In my case, accessing <my_ip>:9101 from the internet, will be mapped to the port 9100 on my RPi.

3. Install Prometheus in Dokku

I'm going to explain how to deploy Prometheus on that droplet using Dokku.

# Create the dokku application
dokku apps:create prometheus

# Create the directory where we'll store the prometheus data
mkdir -p /var/lib/dokku/data/storage/prometheus/

# The prometheus container uses the user `nobody`, so we change the permissions to do that directory writable
# Related: https://github.com/prometheus/prometheus/blob/e963d953eac7d5181024eba2215740835b65c0a9/Dockerfile#L18-L21
sudo chown -R 65534:65534 /var/lib/dokku/data/storage/prometheus/

Locally, we create a new repository and set up a remote pointing to our Dokku host.

# Initialize the repository
git init

# Add a new remote called `dokku` with our dokku host
git remote add dokku [email protected]:prometheus

Now, we have to create the minimum docker environment:

Dockerfile (using the Prometheus image as a base, and just copying the config).
prometheus.yml (with the config to scrape).
app.json (optional, but I'm using the dokku-require plugin, this file configures the mounted volumes).

FROM prom/prometheus

COPY ./prometheus.yml /etc/prometheus/prometheus.yml

Dockerfile

global:
  scrape_interval: 15s # Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "Raspberry"
    static_configs:
      - targets: ["<your_public_ip_address>:9101"]

prometheus.yml

{
  "dokku": {
    "volumes": [
      {
        "host": "/var/lib/dokku/data/storage/prometheus/data",
        "app": "/data/",
        "phases": "run,deploy"
      }
    ]
  }
}

app.json

After committing all these files and pushing to the Dokku server, you should be able to access Prometheus at the default domain, but maybe you prefer a friendlier URL, like https://prometheus.yourdomain.com:9091/.

# Configure your desired domain
dokku domains:add prometheus prometheus.yourdomain.com

# Enable the HTTPS using the letsencrypt plugin
dokku letsencrypt prometheus

# Set the proxy ports
dokku proxy:ports-set prometheus http:9090:9090 https:9091:9090

The last step is to configure the start parameters that Prometheus will use to run the container (more info about the available parameters in the prometheus website):

dokku config:set prometheus DOKKU_DOCKERFILE_START_CMD="--config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/data --storage.tsdb.retention.size=1GB --storage.tsdb.retention.time=30d"

After that, if you open https://prometheus.yourdomain.com:9091/ in your browser, you should see something similar to this under the Status > Targets menu.

List of targets managed by prometheus

And you can start playing with the available metrics from the Graph menu (prometheus query examples).

Recap

In this article we've learned how to consume the metrics that node_exporter generates on our Raspberry Pi, and how to query them using Prometheus.

In the next article I'll explain how to install Grafana in Dokku, and how to connect all the pieces.

References

Prometheus :: Storage Configuration.
Tutorial: Node Exporter in Raspberry Pi.
Github: raspberry_exporter.

Using Youtube on iOS while the screen is off

Sun, 23 Jun 2019 11:00:00 GMT

Some months ago Youtube presented Youtube Premium, a subscription plan that, among other features, lets you keep playing videos in the background (while you're using another app or after you turn off the screen).

This easy tweak will let you keep watching YouTube videos in the background as you did in the past, all without jailbreaking your iPhone / iPad.

TL;DR; using Youtube BG shortcut, you will be able to play YouTube videos in the background from the "Share" menu in the YouTube app.

Requirements

Install Shortcuts app from the App Store.
In the official YouTube app, tap the three dots to open "Share", then tap the More button on the bottom right, and again More in the share menu.

3. Install the Youtube BG shortcut by tapping here.

** Note: if the video's sound stops, you can press play from the bottom menu (as when you change a song in Spotify), and it will play in the background.

How it works

Thanks to youtube-dl, I get the raw video URL, and using the iOS app Shortcuts, you can run the whole flow from the share menu of the official YouTube app.

WeCode' talk about Dokku

Thu, 28 Mar 2019 18:53:00 GMT

WeCode is a really nice conference in Valladolid (Spain) where some slots are open for attendees to present their own talks, so I decided to talk about one of my latest toys: Dokku.

Here is the video of the talk (in Spanish), and the slides.

Turn off display on MacBook Air 2018

Tue, 12 Mar 2019 20:32:00 GMT

As you probably know, the MacBook Air released in 2018 includes TouchID as a way to unlock it. The fingerprint reader is located on the top right, where old Mac keyboards included the Eject key.

You probably didn't use Eject much on your DVD-less MacBook, BUT I used to use a shortcut Ctrl + Shift + Eject to turn off Mac's screen, and this is something that I've missed since I bought my new MacBook Air.

I finally solved it by creating an AppleScript in Automator as a service with the following code.

do shell script ("pmset displaysleepnow")

As we've created a new service, we can assign a shortcut from System Preferences > Keyboard > Shortcuts > Services, in my case, I've assigned Control (^) + Alt + F12 as you can see in the image.

I hope this helps someone, and if you solved this in another way, please let me know :)

Scaling Amazon Aurora at ticketea

Fri, 19 May 2017 12:00:00 GMT

I wrote a post about how we scaled AWS Aurora at ticketea when a big event went on sale.

It was originally published on our engineering blog: Scaling Amazon Aurora at ticketea, but I'm going to include it in this blog too.

Ticketing is a business in which extreme traffic spikes are the norm, rather than the exception. For Ticketea, this means that our traffic can increase by a factor of 60x in a matter of seconds. This usually happens when big events (which have a fixed, pre-announced 'sale start time') go on sale.

Cloud elasticity has its limits, particularly when reacting to extremely sudden changes in the inbound request rate. This is the reason why, for certain situations, we preferred to perform a pre-planned platform scaling followed by a warm-up.
For the sake of context, we host our infrastructure in AWS and we're heavy Amazon Aurora users.

For Ticketea, a big event usually translates to a surge of traffic, which touches the following components:

Frontend app servers serving ticketea.com
API app servers
Background tasks
Relational Databases

The first three resources are easy to scale horizontally (add / remove EC2 instances). We just need to modify their autoscaling groups, and AWS will do the hard work for us.

Relational databases are usually much harder to scale. Even though we're using an AWS Aurora cluster with multiple read replicas, scaling the writer node up and down is usually the tricky part. Before we get into it, let's talk a bit about AWS Aurora and how we're using it.

An Aurora cluster is accessible through two DNS records:

A writer endpoint (a DNS Record pointing to the currently elected writer node)
A reader endpoint (a DNS Record which balances among the reader instances)

Understanding the failover process

Failover is the process that Amazon Aurora gives us to promote a node to the writer role (Aurora only allows one writer at a time). The choice of the future writer node is performed using tiers. A tier is a config value which is set at instance creation time (and can be changed later).

When a failover happens (either manually triggered or in reaction to a cluster failure) Aurora will promote the lowest-tier reader node to the writer role.

As stated before, sometimes we need to scale the writer node vertically. To achieve this result, we force a failover to a beefier instance. Traditionally, we used to do this when the traffic was at its lowest point during the day, because we were afraid of the impact that such operation might have had on our users.
That really didn't work out well for the team (it meant that someone had to wake up early / stay up late), so we decided to do some tests to understand how to improve the failover and recovery times.

The first step was a simple script that issued bursts of queries to the writer node. During the execution, we would perform a manual failover, at which point we'd start to see that some of the queries were OK, but others failed randomly. The errors lasted for a 10-15 second window. We repeated the test several times, and the results were similar.

We decided to investigate how the Aurora writer and reader endpoints were implemented. Running host on the writer endpoint DNS record (let's suppose tkt-aurora-cluster.cluster-abcdefg.eu-west-1.rds.amazonaws.com), reveals that the endpoint is really a CNAME pointing to the currently elected Aurora writer instance.

$ host tkt-aurora-cluster.cluster-abcdefg.eu-west-1.rds.amazonaws.com
tkt-aurora-cluster.cluster-abcdefg.eu-west-1.rds.amazonaws.com is an alias for
tkt-aurora-1.abcdefg.eu-west-1.rds.amazonaws.com
tkt-aurora-1.abcdefg.eu-west-1.rds.amazonaws.com is an alias for ec2-12-123-12-12.eu-west-1.compute.amazonaws.com.
ec2-12-123-12-12.eu-west-1.compute.amazonaws.com has address 12.123.12.12

The reader endpoint works in a similar fashion, with the exception that it's backed by a Round-Robin DNS record pointing to the underlying database instances.

This explains why we were getting some errors during the failover operation: there is a rather large window of time (10-15 seconds) during which the cluster is adjusting to the new topology and DNS records are switched to reflect it. As you can imagine, DNS manipulation and propagation is not an atomic operation, hence the errors.

Scaling procedures

Once we had gathered more information with this small investigation, we defined four different processes to scale our platform while minimizing the impact on our users. Let's have a look at them.

Horizontal scaling of the read cluster

This means adding or removing nodes to our read cluster to increase our read capacity.

Scaling out

Scaling out is really easy: If you use the AWS Console, you can pick your cluster and choose the Create New Aurora Replica option. In our case, a new read replica takes ~7 minutes to be ready, and this operation doesn't cause downtime of any sort. The new node will not be added to the reader DNS endpoint until fully ready.

Scaling in

This is actually a bit tricky. If we have 3 reader instances, and we decide to terminate one of them, the DNS round-robin will propagate with a certain delay, resulting in traffic being delivered to a dead database instance during a certain period of time.

Due to that, we decided to use an additional DNS record in Route53. This DNS record is the hostname applications normally connect to. It normally points to the cluster reader endpoint, except during a scale-in operation. In that case, we temporarily point it to a specific database reader instance, while others are being deleted.

In this way we have exact control over the node where the read traffic is routed to, instead of relying on DNS propagation.

Vertical scaling of the writer node

Since Amazon Aurora is not multi-master, if we need more write capacity, we need to change the writer instance type. This means that we need to create a new Aurora instance with a higher capacity and then promote it to the writer role.

Scaling up

To have more control over the scale-up process, we usually create a new node with more capacity (let's name it new_master). It will be given the tier 0 which means it'll be the first candidate for promotion to the writer role. As explained in the scale-out section, this process takes ~7 minutes with our main database.

After that, we perform a manual failover on the cluster, which will promote new_master to writer. Due to DNS propagation delay, you may see some errors during a 10-15 second window (but your application is resilient to these errors, isn't it? :p)

Scaling down

This process is the inverse of scaling up. We only modify our old_master instance to have tier 0, and perform the cluster failover. Again, it's possible to see some errors during a 10-15 second window.

Final conclusions

Amazon Aurora clusters are managed with CNAME records which point to database instances. It is important to understand how they work to be able to minimize the impact of failover operations.

Having an additional Route53 record gives us more control during the scale-in operation, and it doesn't make the architecture more complex.

We're currently performing these processes manually, which means we're still not 100% satisfied with the solution. We have some ideas, but if you have any suggestions, feel free to leave a comment! Also, if you happen to be interested in this sort of scalability and reliability topics, keep in mind that we're hiring :-)

UIActivityViewController workaround to 'Share in WhatsApp' in iOS

Thu, 19 May 2016 19:06:00 GMT

UIActivityViewController was introduced in iOS 6 as a helper to share texts, links or images between apps.

It's really easy to work with the default services (share on Twitter, Facebook, Mail…), and for several iOS versions now it has also been integrated with third-party apps like Slack or Telegram.

Using it is simple: you only need to create and present a UIActivityViewController as follows:

UIViewController *root = [[[[UIApplication sharedApplication] delegate] window] rootViewController];
UIActivityViewController *activityView = [[UIActivityViewControllerWithoutWhatsApp alloc] initWithActivityItems:shareObject applicationActivities:nil];
[root presentViewController:activityView animated:YES completion:nil];

A typical setup looks like that, but sometimes you don't want to allow sending SMS or emails from your action, so you can set an array of excludedActivityTypes as follows:

activityView.excludedActivityTypes = @[UIActivityTypeMessage, UIActivityTypeMail];

There are several built-in activities, but you can craft your own UIActivity to do specific actions; a good compilation is available in Github/UIActivityCollection.

In our case, because we ran into a bug related to the latest WhatsApp version, which showed this message when trying to share with one of your WhatsApp contacts:

This item cannot be shared. Please select a different item.

We decided to workaround it using URLSchemes, and we found SSCWhatsAppActivity, a UIActivity subclass which shows an icon on share menu, but it appeared next to the original WhatsApp icon, so we needed to remove the latter first.

Logically, we looked for the WhatsApp activity identifier and added it to the excludedActivityTypes array as follows:

activityView.excludedActivityTypes = @[@"net.whatsapp.WhatsApp.ShareExtension"];

But it’s not possible to remove third-party activities from the menu, at least not directly. So, after playing for a few minutes with <objc/runtime.h>, we finally found a private method that seemed related to our purpose: _shouldExcludeActivityType:

#import "UIActivityViewControllerWithoutWhatsApp.h"


@interface UIActivityViewController (Private)
- (BOOL)_shouldExcludeActivityType:(UIActivity*)activity;
@end


@implementation UIActivityViewControllerWithoutWhatsApp
- (BOOL)_shouldExcludeActivityType:(UIActivity *)activity
{
    if ([[activity activityType] isEqualToString:@"net.whatsapp.WhatsApp.ShareExtension"]) {
        return YES;
    }

    return [super _shouldExcludeActivityType:activity];
}
@end

And, you know what? It works! Thanks, Apple, for making it so straightforward.

2013 Retrospective. My 5 Pros & Cons

Tue, 31 Dec 2013 21:54:00 GMT

Just one hour left in 2013, and I would like to do a small retrospective about what 2013 was for me. I really hate this kind of post, because they're egocentric, but I'm really doing it for myself (that's what self-centered means, isn’t it?). Here are my 5 pros & cons of the year.

Well done!

After too long without writing on my old-blog, I decided to start this blog and try to write in English (sorry for my English mistakes, I need to practice :)).
This was the year I read the most in my life. I could start talking about which books I read this year, but ~~my Readmill account~~ explains that better :)
I also took an active part in the community: first at ‘local’ meetings, but this year I gave a talk at Codemotion, a very important conference for me. I also helped as a volunteer at NSSpain, the best event I've attended.
I started to learn new programming languages (Ruby mainly, but I had my first contact with Node.js too), leaving my comfort zone so far (PHP & Obj-C).
I discovered new sports: snowboard & surf. Thanks to my friends for pushing me to do it!

Bad!

This year I traveled very little. In other years I visited several countries, but this year I was very busy with work, so this is one of my 2014 resolutions.
Pocket is a really good tool if you know how to use it. That's not my case: I currently have almost 2000 articles waiting to be read. I’m thinking about removing all of them and starting from scratch. Really, if I haven't read them by now, what would change?
I started going to the gym and I quit. I started running regularly and I quit once more. I need to be more consistent with exercise (I say it again).
I need to improve my English. I read more and watch more English TV series & films, but my level is still low.
I have to spend more time with the people who really matter. Until now, work was my excuse, but one month ago I joined ticketea, so I hope to have more time for people (sorry guys).

Maybe at the end of 2014 I’ll be able to look back at these resolutions and smile :)

I'm ticketero

Mon, 02 Dec 2013 21:12:00 GMT

I’m very proud to announce that as of today I've joined the ticketea team (a ticketing company based in Spain) as an iOS developer.

For the last two years I was split between management, dealing with customers, and finally development tasks, so I wanted to focus on my real passion: development.

Primer día ^^ (at @Ticketea) [pic]: http://t.co/wxx5zkKIOY pic.twitter.com/pOfopJAa4G
— Jorge Maroto (@patoroco) December 2, 2013

These days have been very intense, but I’m really happy with my new workmates :)

Thank you all for the congratulations & two.

Pucela Testing Days. Testing iOS Applications

Sat, 30 Nov 2013 20:12:00 GMT

As some of you know, I usually attend Cylicon Valley, a developer community at Castilla y León.

This month, we organized a series of talks about testing called Pucela Testing Days (webarchive), so I took part with a talk about the state of the art of iOS testing.

Here is the video (sorry about the quality, I recorded it myself, so please focus on the audio and check the slides).

Codemotion 2013. Introduction to Cocoa Pods

Sun, 20 Oct 2013 08:38:00 GMT

As I announced some weeks ago, I was at Codemotion talking about CocoaPods. If you want to start using this useful Ruby gem, check out my slides (Spanish)!

NSSpain 2013

Fri, 20 Sep 2013 10:01:00 GMT

A few months ago I first read on Twitter about 'the first iOS dev conference' in Spain. At first it seemed like another conference with some popular Spanish developers talking about common topics, but when the organizers started to announce who was coming, I realized that it would not be a typical meetup.

The first surprising thing was that ALL the talks would be in English, because many of the speakers would be international celebrities, so the event would be followed around the world.

The second interesting thing for me was that it would be a four-day event, something very different from the events I usually attend, so with that much time it's possible to talk freely with the speakers and enjoy Logroño’s nightlife during its patron saint’s festival. That was the third reason to finally contact Borja & Luis (the organizers) about the possibility of volunteering, and the result is below (thanks for the photo @juanriaza) ;)

Being a volunteer allowed me to be in contact with everyone, and I enjoyed it because I also attended many talks by VERY smart people such as @orta & @fabiopelosin talking about our loved CocoaPods, @NachoSoto explaining how to improve our Core Animation work with a quick review of different ways to do it, or @steipete, whose talk I could not attend, but where people’s heads exploded trying to understand how the Obj-C runtime works.

If you want, I started a compilation with some of the slides from this NSSpain, which is available in my gist NSSpain-Summaries. I can only recommend that you attend next year, and see you there :).

Codemotion 2013

Fri, 13 Sep 2013 08:01:00 GMT

Codemotion is an event to meet developers from different technologies and places, and it takes place in several countries (see them all at Codemotion World).

Last year was the first edition in Spain, and I was there as an attendee, even recording some videos about storyboard in Xcode or how to monetize apps. I also saw some talks about Cocos 2D or development for Kinect, but unfortunately my iPhone's battery didn't last as long as I wanted...

This year I decided to submit a talk when they opened the call for papers, and it has been included in the schedule!

If you want to learn a little bit about what CocoaPods is, I'll be happy if you attend the talk: 19th October, 11:30 - 12:15 in track 6 webarchive::codemotion.es.

See you there! :)

Giving a little soul

Thu, 12 Sep 2013 17:17:00 GMT

I've finally put some order in the web version of AFNetworking book, with the help of Octopress + Octopress themes, so from now on I hope to focus my work on improving the content of the book itself.

If you don't know what this is, I advise you to read the disclaimer and don't forget you can collaborate through github and download the book in .epub and .mobi for your favorite reader.

Editing 404 page on Github pages

Sun, 08 Sep 2013 09:52:00 GMT

By default Octopress doesn't include a 404 page, so on GitHub it's shown as follows:

Usually, with a Rack server you need to modify the config.ru file to handle exceptions (this website explains this case), but in my case I can't manage the server side, so GitHub gives us another way: they use a 404.html file as the default 404 page, as you can read on their documentation.

In summary, you need to create a new file at the path sources/404.html and it will be used as 404. You can see what mine looks like in 404.html, and this is the code:

---
layout: default
---
<h1 style="text-align: center">Page not found</h1>
<p style="text-align:center">You can find other posts on <a href="https://jorge.maroto.me/archives">Archives</a> of this blog, or directly go to <a href="https://jorge.maroto.me/">the main page</a></p>
<img src="https://jorge.maroto.me/images/404.png" style="max-width: 100%; margin: 0 auto; display: block" />
<small style="display:block; float:right">Credits of the image: <a href="http://refinedmobile.com/404">refinedmobile.com</a></small>

Configuring Octopress

Sat, 07 Sep 2013 19:15:00 GMT

In the last post I talked about how to deploy octopress on github with your custom domain, but it needs a bit of configuration to be the way I like it. You can find more info about that in Octopress configuration, but if you want to know which steps I followed, open the _config.yml file and modify these lines:

...
permalink: /:year/:month/:day/:title/
...
category_dir: categories
...
paginate: 5
pagination_dir:   # It's blank because I don't want /blog before each link page

I found a post about SEO for Octopress websites which explains why and how to remove the redundant /blog prefix, so I followed it :).

After that, there is a section with 3rd party settings for different social networks and services. I think they are self-explanatory, so I'll just give a few tips:

How do you find your G+ user id?
Octopress is a static blog, so if you want comments, you need to use something like Disqus. It's easy (and free!) to create an account, so visit disqus website and fill your id on _config.yml.

Deploying Octopress on github with your domain

Sat, 07 Sep 2013 08:01:00 GMT

I started writing this post because I want a place to remember how to (quickly) install another Octopress, and I'm too lazy to read again all the documentation.

I followed steps explained on Octopress documentation, but mainly it consists of cloning the Octopress repo and installing the required gems:

git clone git://github.com/imathis/octopress.git jorgemaroto.es
cd jorgemaroto.es
bundle install #

After that, you need to create a repository on GitHub, as explained in their github guide, you can choose between two options.
In my case I'm going to create a repo with my name (patoroco.github.io), so after that I can push all the content to the master branch. At this point, you can run the rake task, which works as a wizard to configure everything.

rake setup_github_pages
rake install

By default it uses the classic theme, but I was looking for other options, and finally I decided to use darkstripes theme, so if you want to try it, follow these steps:

git clone git://github.com/amelandri/darkstripes.git .themes/darkstripes
rake install['darkstripes'] # again, this will ask you about overriding your current theme

At this point, you can run rake preview on your terminal, and your site will be available on http://localhost:4000.
OK, this is a good time to publish your blog and start sharing with your friends how cool you are, so first of all you need to create a new repo on your GitHub account with your username, in my case it was http://patoroco.github.io. This would be enough, but I want to use my own domain, so I created a file named CNAME inside source folder (that's jorgemaroto.es/source/CNAME), with the name of my domain:

jorgemaroto.es

Obviously I needed to change my domain configuration, so I recommend that you check Github Pages with custom domain page, because they explain it better than I do :).

Finally, you need to edit some parameters in the _config.yml file as follows:

url: http://jorgemaroto.es
title: Jorge Maroto
subtitle: Trying to write a blog (again).
author: Jorge Maroto
simple_search: http://google.com/search
description: Here I'll try to write a blog somewhat more technical than in the past, and in English!

After that, you can run rake deploy, and you can now access your website using the selected domain (it could take a few hours).

It's important to highlight that with rake deploy, you are only uploading static files to GitHub, so it's recommended to also push your source files (that is, Markdown files, Sass, etc.) uncompiled.
Octopress makes it very easy because you always work on a branch named source, and when you deploy to the master branch, it does that automatically, so at this point you only need to push your source branch:

git push origin source

In the next post, I'll explain the configuration I did to customize the title, social networks, and more.

Why Octopress?

Fri, 06 Sep 2013 20:01:00 GMT

Here I am, trying to write a blog again. This time I hope to be more consistent than last time, and I'm also trying to write in English (sorry for any spelling errors), so this is a big challenge for me.

Ok, and... why Octopress? My answer is 'why not?'. I've used WordPress for several years, both for personal projects and for work, and I really like it and PHP, but it was time to try other things, and I decided to start to play with Ruby, so let's say that this is a mix of all these things.

I would like to list some of the things that made me choose Octopress:

My blog died. Really not, but I've gone almost two years without updating it, so I started to think about a change.
I want to practice and improve my English, so I decided to create a new blog, mainly in English.
I like markdown, it's easy to read and edit, it's multi-platform, and there are several apps to work with it (I use Mou, because it's simple and free) and plenty of documentation (Daring Fireball, where Markdown was born).
It's a good reason to play with Ruby, even if I only edit some plugins, I'll be improving my Ruby skills.
Octopress comes from Jekyll, so it has many plugins that make every typical blogging task easy and a big community.
Finally... It's cool, and I feel like a hacker! Did you know that I can write this post on my iPhone in Markdown, share it via Dropbox and deploy it to GitHub easily? Furthermore, you can make a pull-request to improve/complete/fix any post. Kevin Mitnick would dream of this!

I hope to write several posts about how to install and configure Octopress, so stay tuned if you're interested.