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 hubieron 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 in the first part we did with prometheus, we'll create the Dokku application, and allow to Grafana to write in 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/

In our local, 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 the Grafana as base, we'll include the specific configuration for nginx)
nginx.conf.sigil (just to increase the size limit when we do POST using grafana, for example to do snapshots of some 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

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 push to our Dokku repository, we'll be able to connect using the default domain and port, but we could setup those:

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

You can open now Grafana.mydomain.com in your browser, and introduce the default user: admin / admin.

5. Connecting Grafana to Prometheus

Grafana and Prometheus are working in two different containers, so if we want that Grafana 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 to do some queries over prometheus, there are a bunch of examples on their website.

6. Importing a node_exporter dashboard

An interesting feature of Grafana, is the capability to import dashboards, even they have a repository with a lot of these.

Thanks to that, we can find a Node Exporter Full dashboard, which we could 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 discovered 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 get monitored a server, from a Raspberry Pi in your home, to a more professional setup in your company, because you can even define alarms to get notified when something is going 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

The last weeks, I've been having some issues with my Raspberry Pi, which unexpectedly stopped working after some 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 in a monitoring solution (time series based, alerting, etc), and one of their 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 in the smallest dropplet in Digital Ocean (5$/month).

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

Export the metrics from the Raspberry Pi using node_exporter.
Do the metrics accessible from internet (as we'll run Prometheus in a Digital Ocean dropplet).
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 in download the package from the releases tab in Github, and execute it (these commands are run in 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 the Raspberry Pi model 3, so I've downloaded the ARMv7 release from the list.

Once you run the command, you could visit http://<raspberry_IP>:9100/, and press in the metrics button, in my case it will link 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 that your raspberry needs to restart, 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 autostart as you expected

2. Doing accessible node_exporter from Internet

As we'll have our Prometheus hosted in an external server (Digital Ocean in my case), we have to do our RPi accessible from the internet.

Doing that could be different depending on the router you have, so I gonna share a screenshot of my router's configuration, where it's only needed to set up the port to be mapped to the RPi, in my case, accessing to <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 in 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/

In our local, we create a new repository and setup a remote with 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 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 commit all these files, and push to the dokku server, you should be able to access to the prometheus in the default domain value, but maybe you prefer to access in a more friendly 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 just to configure the start parameter 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 could start to play 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 from our Raspberry Pi, and querying these 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 suscription plan that between more features, allows you to continue using video in background mode (while you're viewing another app or when you decide turn off the screen).

This easy tweak will allow you to continue seeing Youtube videos in background as you did in the past, and everything without require Jailbreak for your iPhone / iPad.

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

Requirements

Install Shortcurts app from the AppStore.
From the official Youtube app, press the three dots to show the "Sharing", and once in, press the More button on the bottom-rigth, and again, More in the share menu.

3. Install the Youtube BG shortcut pressing here.

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

How it works

Thanks to youtube-dl, I'll get the raw-video URL, and using the iOS app Shortcuts, you will be able to run all the flow from the sharing 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 opened to present yourself talks, so I decided to talk about one of my last toys: Dokku.

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

Scaling Amazon Aurora at ticketea

Fri, 19 May 2017 12:00:00 GMT

I wrote a post about how we scaling AWS Aurora at ticketea when we go to sell some big event.

Originally it was available on our engineering blog: Scaling Amazon Aurora at ticketea, but I gonna include 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 prefered to perform a pre-planned platform scaling followed by a warm-up.
For the sake of context, we host our infrastructure in AWS ad 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 up and down the writer node 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 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 queries were OK, but others failed randomly. The errors lasted during a 10-15 second window. We repeated the test several times, and 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 gathered more information with this small research, 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, it's possible to see some errors during a window of 10-15 seconds (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 default services (share on Twitter, Facebook, Mail…), and since several iOS versions, it's also integrated with third-party apps like Slack or Telegram.

Use 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 sometime you don't want to allow to send SMS, or Mails 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 yourself UIActivity to do specific actions, a good compilation is available in Github/UIActivityCollection.

In our case, and because we suffered a bug related with last WhatsApp version, which showed a message when try 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 this first.

As logic indicated, we looked for whatsapp activity identifier, and add to excludeActivityTypes array as follows:

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

But it’s not possible to remove third-party activities from menu, at least directly. So, after play some minutes with <objc/runtime.h>, we finally found a private method which seemed to be related with 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 to do that so straightforward.

Pucela Testing Days. Testing iOS Applications

Sat, 30 Nov 2013 20:12:00 GMT

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

This month, we organized a serie of talks about testing named Pucela Testing Days (webarchive), so I've collaborated talking about state of the art of iOS testing.

There is the video (sorry about the quality, but I recorded it myself, so please, attend to the sound 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 in Codemotion talking about Cocoa Pods. If you want to start to use this useful ruby gem, check my slides (spanish)!

NSSpain 2013

Fri, 20 Sep 2013 10:01:00 GMT

Few months ago was when I first read on twitter about 'the first iOS-dev conference' in Spain. At first it seemed another conference with some popular spanish developers talking about common topics, but when organizers started to show who were coming, I realized that it would not be a typical meeting.

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

Second interesting thing for me was that it would be a four-days event, something very different from events as I usually assist, so with so long is possible to talk freely with speakers and enjoy of Logroño’s night in their patron’s saint day, this was third reason to finally contact with Borja & Luis (organizers) asking about posibility to be volunteer, result is below (thanks for the photo @juanriaza) ;)

To be volunteer allowed me to be in contact with all people, and I enjoyed it because I also attended many talks with VERY smart people as @orta & @fabiopelosin talking about our loved CocoaPods, @NachoSoto explaining how to improve our Core Animations with a quick review of different ways to do that, or @steipete, talk which I could not attend, but where people’s head explode trying to understand how obj-c runtime works.

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

Codemotion 2013

Fri, 13 Sep 2013 08:01:00 GMT

Codemotion is an event to meet up with developers of different technologies and places which takes place in several countries (look all at Codemotion World).

Last year was the first event on Spain, and I was there as public, even recording some videos about storyboard on XCode or how to monetize apps. I also saw some talks about Cocos 2D or development for Kinect, but unfortunately my iPhone's battery does not last as long as I wanted...

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

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

See you there! :)

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 showed as follows:

Usually with a rack server it's needed to modify config.ru file to manage exceptions (this web explain this case), but in my case, I can not manage server side, so Github give us another way: they interpret a 404.html file as a default 404 page, as you can read on their documentation.

In summary, you need to create a new file at path sources/404.html and it will be used as 404. You can see how mine is in 404.html, and that's 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

On the last post I talked about how to deploy octopress on github with your custom domain, but it needs a little bit config to be as I like, you can see more info about that on Octopress configuration, but if you want to know which steps I followed, open _config.yml file and modify this 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 explain why and how remove redundant /blog prefix, so I followed it :).

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

How do you find your G+ user id?
Octopress is a static blog, so if you want to have comments, you need to use some like Disqus, it's easy (and free!) 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 to write this post because I want to have some place to remember how to install (quickly) another octopress, and I'm too lazy to read again all the documentation.

I followed steps explained on Octopress documentation, but mainly it consists on clone Octopress repo and install 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 they explain on their github guide, you can choose between two ways.
In my case I going to create a repo with my name (patoroco.github.io), so after that I can update all the content to master branch. At this point, you can execute rake task, which will be a wizard to configure all.

rake setup_github_pages
rake install

By default it uses classic theme, but I was looking 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 to share with your friends how cool you are, so first of all you need to create a new repo on your github with your username, in my case it was http://patoroco.github.io. This would be enough, but I want to use myself domain, so I create 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 make a change on my domain configuration, so I recommend you that check Github Pages with custom domain page, because they explain it better than me :).

Finally, you need to edit some parameters on _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 to your website using selected domain (it could take some hours).

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

git push origin source

On the next post, I'll explain which configuration I did to customize title, social networks, and other.

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 constant than last time, besides trying to write in english (sorry for the spelling errors), so this is a big challenge for me.

Ok, and... why Octopress? My answer is 'why not?', I've used with Wordpress for several years, both personal as for work, and I really like it and PHP, but it was time to try another 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 name some of the things that made me decide by octopress:

My blog died. Really not, but I've been almost two years without update 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 exist several apps to work with it (I use Mou, because it's simple and free) and much documentation (Daring Fireball, where markdown 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 come from Jekyll, so it has many plugins to do easy each typical blogging task and a big community.
Finally... It's cool, and I feel like a hacker! Do you know that I can write this post from my iPhone on markdown format, share with Dropbox and deploy on github easily? Further, you can make a pull-request to improve/complete/fix any post. Kevin Mitnick would dream with this!

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