Como usar grupos de whatsapp, conservando a tus amigos y tu batería!!

Introducción

Hace un tiempo que utilizo WhatsApp y desdé hace aproximadamente un año empecé a usar los servicios de grupos, lo cuáles sin la correcta configuración se pueden convertir en una tortura más que en un placer.

Acá recopilo algunos consejos que me han ayudado a sobrevivir y no quedarme sin batería a las 5 de la tarde cuándo lo que menos tengo ganas es de poner mi celular a cargar

Desactiva todas esas horribles notificaciones en los grupos!

Whatsapp por suerte permite configurar distintas opciones de notificaciones tanto para contactos como para grupos, en Android por ejemplo por defecto usa 3 notificaciones: sonido, vibración y luz! Esto no sólo gasta batería (Y MUCHA si te llegan 10mensajes por minuto), sino que también se puede convertir en una molestia y querer notificarte en el momento menos adecuado, por ejemplo cuándo estas durmiendo, hablando con un amigo…. etc.

Para configurar las notificaciones de grupo te vas primero a la ventana principal del whatspapp (ahí dónde están todas tus conversaciones, arriba dice chats por ejemplo) arriba a la derecha tenes un botoncito que tiene 3 cuadraditos uno arriba de otro, como si fueran 3 puntos pero puestos verticalmente, te va a abrir un menú, elegí la opción Ajustes.

Luego del nuevo menú toca en notificaciones, baja en el nuevo panel hasta que te dice Notificaciones de grupo allí en Tono de notificación apreta y selecciona Ninguno!, luego selecciona Aceptar, siguiente opción es Vibrar, si querés que tu batería dure más de 2h al día te recomiendo seleccionar Apagado, luego en la ventana Notificación emergente es mejor seleccionar Ningún mensaje, sino las notificaciones de grupos o te gastan la batería prendiendo la pantalla cuándo el celu está en tu bolsillo, o te molesta al leer ese mensaje que sí querías leer. La última opción Luz te sirve sólo con algunos celulares como los Motorola que tienen una molesta luz de notificación, seamos sinceros a quién carajo se le ocurre poner un led de alta potencia azul en un dispositivo que uno pone en la mesita de luz??????? Para evitar el encandilazo que te despierta 3am porque algún amigo pelotudo manda un mensaje elegí Ningún.

Si creas grupos encargate de eliminarlos!

Hay gente que parece divertirse creando grupos y agregandote, lo cuál es molesto porque después son los primeros en borrarse del grupo, cambiando whatsapp el administrador automáticamente y dejando cientos de grupos zombies flotando en tu celular, en caso de que seas una de esas adorables personas por favor tene el buen gesto  de REALMENTE ELIMINAR el puto grupo!  Para ello los pasos a seguir son sencillos: abrí el grupo, toca sobre el nombre del grupo, toca cada nombre de los otros usuarios y eleminalo, por último una vez que el grupo sólo te tiene a vos como usuario elegí eliminar y salir de grupo.

Conclusiones

Si queres conservar a tus amigos y tu batería mejor saber primero el celular antes de comprarte un yate de bolsillo, y para variar apagaló! hablar cara a cara con la gente es aunque no lo creas mucho más divertido.

 

Advertisements
| Leave a comment

Notes on cross compiling apps that depends on Qt4 from Linux with Mingw

This is are just some remind notes for my self for future reference:

    • Install QtSdk (couldn’t do it with Wine used virtualbox)
    • Copy c:\QtSdk\Desktop\<version>\mingw folders include, mkspecs, translations, lib and plugins into the host
    • Pass -L and -I accordly

Move this content into

| Leave a comment

Pulling changes from one branch to another in git

Sometime ago I had the nice idea of suggesting my boss we should rewrite the build system, to automate many tasks we were doing by hand or scripting, our old build system was based on SCons so I took this awesome tool as base, thing is I ended up writting a few tools, and now we are in the stage of merging things.

Problem is that many of our project where a mess when it comes to include paths and defines, we had things like include paths that referenced files inside directories from projects, instead of the root of the project, exposing internals, then we had many aweful things like:

#define HEADER_IMPL <somefile.h>

....

#include HEADER_IMPL

So I did many modifications to the projects to make it look nicer, and easier for new people to jump into development without having to guess what the heck was going on under the hood, now we have something as:

#define HEADER_SOME_FILE 

....

#ifdef HEADER_SOME_FILE
#include <somefile.h>
#elif defined HEADER_SOMEOTHER_FILE
#include <somefile-other.h>
#else
...
#endif

Problem is I ended up with about 200 commits in git, and the branch I was working on was all ready a topic branch, so then the pain started over, merging those changes back into the master branch, now here’s the problem….. we can’t just merget! Because that would break some of the company products, so I needed a way to control what got merged and what not.

I investigated a little and come up with a not as elegegant as I want solution, but good enough anyway:

git format-patch FIRST_COMMIT..LAST_COMMIT
git am --reject *.patch

The first command will extract all the patches and format them for mailing, the second one wills start applying one after the other, and if by some reason a patch fails to apply it will generate .rej files and let the user interact before going on. Once the issue is solved you need to do:

git am --resolved

Off course this isn’t as nice as merging, but unfortunately I have no other way to handle this, as we need the new build system in the old branch, while still can’t merge the changes the made master and my reference branch diverge.

 git am --3way

wouldn’t work either as it would pull some of the changes anyway.

Posted in git | Leave a comment

PyDay Rosario 2013: Principal

Ideal para aquellos que quieran aprender un poco de que se trata Python antes que se realice la PyCon 2013 acá en Rosario

1° Jornada de Python en Rosario – Santa Fe

via PyDay Rosario 2013: Principal.

 

| Leave a comment

Freescale Freedom Development Platform FRDM-KL25Z programming with Linux

I got this nice board about a month ago, and yet I couldn’t find the time to play much with it… until today.

I unboxed the board a couple of weeks ago, and I noticed the only way to program it was with a REAL Windows box (couldn’t get VirtualBox to work at first!) BIG BIG BOOMER!

Today I took over the board again and was able to get VirtualBox to recognize the board (nice getting somewhere!), in order to do this I needed to add USB devices filters, hot-plug to the VM didn’t work, but the filters did the trick. It makes sense a filtered device will give control to the guest OS as soon as the device is detected, and not letting Linux play with the crappy factory fw.

So I started playing around a little, and was able to program the board, get it into bootloader mode and such. Still not a close to nice solution but better than rebooting my dual boot into useless Windows just for playing with a board….

Then I started looking around on the web and got to this post [1], nice they give some details, but not totally helpful.

So I grabbed [2], got the board into bootloader mode a file named BOOTUPDATEAPP.SDA to get the bootloader updated, unpluged the board and plugged it back into bootloader mode once more, this time I pushed MSD-FRDM-KL25Z_Pemicro_v107.SDA and did the plug process once more to verify it still was working on Windows.

Once Windows was doing it fine, I disabled the usb filters, took out the wire, put it back in and BOILA!!! Thunar from XFCE now allows me to drag and drop .sda files to the ARM processor.

Now time to start playing with GCC and SCons to get a toolchain working. 

[1] http://www.element14.com/community/thread/20182?start=15&tstart=0

[2] http://www.pemicro.com/downloads/download_file.cfm?download_id=378

| 5 Comments

Migrating large svn repositories into git

Introduction

While working at Evolution Robotics (now part of iRobot) I was in charge of migrating some of they’re svn repositories into git, one was in particular was really complicated and forced me and my colleague to learn lots of the internals of the migration tool, svn and git. This repository had over 12000 commits, 100 branches and tags, many subprojects inside we needed to split, all together making a mess, with non regular branching rules, commits that modified lots of files, etc.

The initial migration attempt I made was by using git over svn, but it didn’t correctly migrated tags and branches, and was incredible slow to work with. Then my boss told me about svn-all-fast-export so I gave it a try, and felt in love with it.

svn-all-fast-export is a tool developed by the KDE team that lets you migrate svn repositories into git, you can get this tool from here.

This tool uses rules that get parsed and applied to an svn sync copy, not a regular svn copy, you need some repository information not available with svn copy, you can make this copy over the svn protocol, so no special permissions are needed.

svn sync copy

I will not explain much about this rules, just tell you they work, and you can use it to create an svn copy of a repository.

# this steps needs to be run only once
# replace ${SVN_COPY} with the folder where you want to store it.
# replace ${SVN_URL} with the url you want to clone from.

$ svnadmin create ${SVN_COPY}

$ cat << 'EOF' > ${SVN_COPY}/hooks/pre-revprop-change
#!/bin/sh

USER='$3'

if [ "$USER" = "svnsync" ]; then exit 0; fi

echo "Only svnsync user can change revprops" >&2
exit 1
EOF

$ chmod +x ${SVN_COPY}/hooks/pre-revprop-change

svnsync init \
        --username svnsync \
        file://`pwd`/${SVN_COPY} \
        ${SVN_URL}

Then each time you want to synchronize (or after the first time you executed the previous lines)

# replace {SVN_COPY} with the name of the directory where you are
# storing the svn clone

$ svnsync sync file://`pwd`/${SVN_COPY}

Writting rules

The quality of your migration depends a lot on how much you can automate. After all, the task is tedious and repetitive, and you don’t want to screw it up, specially when you have thousands of commits, or are splitting one repository into several smaller ones.

There’s one problem though, documentation for svn-all-fast-export isn’t very explicit, and is kind of outdated, so you will have to read the code in order to understand what’s going on, or what is allowed in the rules file. In case you want to play around with the code you should look into src/ruleparser.cpp.

Simple explample

Let’s start with the minimal config we can have.

create repository project1
end repository

match /project1/trunk
   repository project1
   branch master
end match

match /
end match

Let’s do some explanation before we go any further

create repository project1
end repository

This rule will create a git repository named project1, you should note that if folder project1 exists and it’s a git repository it will not get overwritten, BUT if you are not careful you may end up with many disconnected git objects. Most of the time you shouldn’t worry about this, as svn-all-fast-export is smart enough to resume accordly, but be warned.

match /project1/trunk/
   repository project1
   branch master
end match

This rule will match any path that inside {SVN_REPOSITORY}/project1/trunk/* to project1 on branch master. Make sure you understand what this means before going on. It’s a very important concept, and it’s rather easy to forget about it while you’re righting rules.

NOTE: Don’t forget about the extra slash after your path, otherwise the tool will crash or blame, and you will get your hairs out for just a stupid missing slash (true story happened me a lot).

It’s worth to mention that matches can make use of regular expressions and all it’s features, like grouping and substitution.

Repository creation

The first thing you need to do is tell svn-all-fast-export which are the repositories it will use, this rules are going to be executed before the first commit is processed. I’m not sure if they need to be the first thing in the config file, but it’s nice to do it.

The rule for creation is:

create repository [PATH]
<description [TEXT]>
end repository

[PATH] is the path where the repository is going to be stored, a nice non documented feature is that the repository can have slashes in the name, meaning you can create a directory structure with your git repositories if you want, so in our rules we ended with something as:

common/
    repo1.git
    repo2.git
specific/
    repo1.git
    repo2.git
somethingelse/
    repo1.git
    repo2.git

It’s worth to mention that somethigelse/repo1.git is not the same as common/repo1.git. Also as the results you get are bare repositories it’s better if you add .git to the path name.

 <description [TEXT]>

is an optional rule that lets you set the repository description (file git/description), if you will later be pushing this bare repositories into your central repositories then you should make use of this optional feature, otherwise it will not be honored (at least gitolite doesn’t do it).

Helpers

svn-all-fast-export has many helpers, with most non been documented.

Variables

Variables can easily be created, this is a nice feature that we used when splitting repositories. For example this will let you have one variable which will hold the name of all your repositories, so you don’t have to type them over and over.

declare VARIABLE="content"

Example usage:

create repository something/project1.git
end repository

create repository something/project2.git
end repository

declare PROJECTS=(project1|project2)

match /trunk/${PROJECTS}/
     repository something/$1.git
     branch master
end match

Importing rules

In complex projects is very easy to end up with rule files that are thousands of lines long, if you are used to read code like I am, you may also get upset when you see code that has thousands or tens of thousands lines, and what you do to avoid is splitting code into several files, and then importing it. So why not doing it in the migration rules? Lucky for us there’s a way to do it.

import [FILE]

Where [FILE] points to the file you want to load. Files are loaded from the rules file folder, so you non absolute references will match the same directory as the caller file.

import will open [FILE] and copy the content of it into the line that says import. Same file can be imported multiple times.

Matching rules

| Leave a comment

Split folder from project with full history, branches and tags

This simple script allows to split a folder from a project (make a backup first!), and will keep all branches and valid tags that use this folder.

#!/bin/bash

URL=$1
FOLDER=$2
SPLITTER=$3

set -e

function git_extract(){
     pushd $1

     git remote rm origin

     echo "Extracting $2 from $1"
     echo "Original size $(du -h -s .)"
     for TAG in $( git tag -l ); do
         if [ -z "$(git ls-tree refs/tags/$TAG $2)" ]; then
            echo "$TAG will be deleted"
            git tag -d $TAG
         fi;
     done

     for BRANCH in $( git branch -a | grep -v master | grep -v branches ); do
         if [ -z "$(git ls-tree refs/heads/$BRANCH $2)" ]; then
            echo "$BRANCH will be deleted"
            git branch -D $BRANCH
         fi;
     done

     git filter-branch \
           --subdirectory-filter $2 \
           --tag-name-filter cat \
           --prune-empty -- --all
     rm -rf refs/original

     if [ "$3" == "mark-split" ]; then
         git filter-branch --msg-filter '
         cat &&;
         echo ""
         echo "Splitted-from: $4"
         echo "Splitted-by: $5"
        ' --tag-name-filter cat -- --all
     fi
     rm -rf refs/original logs lost-found
     git reflog expire --all
     git gc --prune=0 --aggressive # shrink the project please!
     echo "new size $(du -h -s .)"
     popd
}

git clone --mirror --bare $URL split-base-mirror

git_extract split-base-mirror $FOLDER mark-split $URL $SPLITTER

The script takes 3 arguments: url from which we get the repo, folder we’re splitting and your Name for tagging it.

Posted in git | Leave a comment