Free leach torrents switch

In case you use lztr us, what.cd, pass the popcorn or anything based on project gazelle, which you shouldn't be doing because it's illegal, you can try passing &freetorrent=1 to torrents.php (in the url bar) and it will list all free leach torrents available at the moment. Just sayin'.

Dell touchpad recognized as PS2 mouse

I just want to put this online in case somebody has the same issue.

So here's my setup -- I have a Dell Latitude E6430 laptop. I have arch linux installed on it, and the touchpad was recognized as PS2 mouse, hence multitouch gestures were not working, including two-finger scroll and multitouch tapping.

A friend of mine suggested that this was actually not an elantech touchpad, but an ALPS one (low cost elantech). So a different driver was needed. The package that fixed the issue for me was psmouse-alps-driver from AUR. In case you use a different linux distro, try this url -- from the guys who wrote it. It is a replacement psmouse kernel module, built with dkms.

Commands you might find useful:

dmesg | less

and search for PS2

modprobe -r psmouse

remove old psmouse driver

modprobe psmouse

reinsert psmouse driver (after installation)

dkms status

see status of dkms managed modules

xinput

list X input devices

Update 16 Nov 2012

And everything works flawlessly until you decide to upgrade your kernel. You may imagine what would happen with your custom-compiled kernel driver. Just issue dkms autoinstall to recompile the driver against the current kernel, and then modprobe -r psmouse to remove the old one (if any) and modprobe psmouse to insert the new one.

And thats it! Until you upgrade your kernel ...

If you're using arch linux you can enable the dkms.service: sudo systemctl enable dkms.service, so it would do that for you on reboot.

git goodness (pt. 1)

This post is intended for people, who know the basics of git and want to go to the next level ;-)

Branches

A git branch is just a reference to a commit. You can easily change the reference by git reset --hard <refspec>. The first time you do this you are most probably going to lose some commits :) To see the commits you were on recently, try git reflog, and then another git reset --hard <refspec> to point your branch to the right commit.

Remote branches

These are branches on remote repositories. They are read only -- that is, you can not change where they point to by hand. You can update them with git fetch <remote>. Note that git pull does a fetch and a merge/rebase, so it would update them too.

By default you do not have local branches representing all remote branches, just for master. If you have a remote origin with a branch coolbranch, just use git checkout -b coolbranch origin/coolbranch

Deleting remote branches is odd. Use git push origin :branchtodelete and don't ask me why :)

Tracking branches

You can specify that a local branch is linked to a remote branch, so that git pull and git push work without additional arguments.

If you created a new branch on your local machine and want to push it (to say, github.com), you would do git push -u origin newbranch. -u tells git to set newbranch as tracking origin/newbranch.

When you start working on a new branch from origin, if you do git checkout -b branchname it sets local branch branchname as tracking origin/branchname.

gitconfig

User-wide git configuration resides in ~/.gitconfig. Here is mine, I think its good enough to be shared ;-)

[user]
  email = your.name@email.com
  name = Your Name
[alias]
  st = status
  ci = commit
  co = checkout
  l = log --graph --decorate --pretty=oneline --abbrev-commit --all
[color]
  diff = auto
  log = auto
  status = auto
  branch = auto

Aliases are a great way to save you from typing the most common commands. I also had the habit of using st and co from svn and mercurial, so if you're also used to that add them in.

Everybody likes fancy colors nowadays (even me!), they also make the output more readable. To enable colorful output just include the [color] section and list the commands you wish to see in color. You can also specify the colors used, check the docs for more info on that

Read more about the long line in the next section

history

Checking the repo history is a fundamental operation. I'll explain the most useful options here:

git log <commit>

Lists all ancestor commits of the given commit, or HEAD if no commit is given. The commit hash, the author and the full commit message are shown. Use this if you want to search the history for a given commit (sha128) or words you hope to find in the commit message.

git log -p <commit>

The same as above, but also include the diffs of each commit. Very handy if you want to check the history of something in the source code like a function or variable.

git log <path/to/file>

You may also check the history of a particular file.

git log --graph --decorate --pretty=oneline --abbrev-commit --all

I use this recipe to get an ascii graph of all commits in the repo. I use it so often that I aliased it with git l (check gitconfig above). Experiment with a subset of the options to see what they do.

To be continued...

This turned out longer than I expected. I hope I can post more on this topic, more specifically interactive add, rebase, cherry-pick. Stay tuned.

keybinds in console

Наскоро научих как точно се настройва коя клавишна комбинация какво прави в терминала. Сега ще споделя това знание... за да може като го забравя да си го прочета от тук :)

клавиши и комбинации

За съжаление, комбинациите не се задават в някакъв четим формат а приличат на нещо от сорта на ^[Od (ctrl + left arrow при мен) или ^[^[[D (alt + left arrow). За да разберете коя комбинация, на каква последователност отговаря стартирате read, натискате и гледате какво излиза на екрана. Ето какво излиза при alt+up, delete, end на моята машина:

[iskren ~]% read
^[^[[A^[[3~^[[8~

После заместваме ^[ със \e като пишем последователностите, т.е ^[^[[A става \e\e[A, ^[[3~ става \e[3~ и т.н.

команди

След като харесате кой клавиш искате да прави нещо, трябва и да обясните какво точно искате да прави :) За да видите списък със всички команди, в терминал (zsh only tested) натискате alt+x tab tab. В общи линии това са extended commands стил emacs но има и други.

клавишни комбинации + команди

Сега остава да напишете някъде коя комбинация, коя команда искате да стартира. Единия вариант е да ги сложите в /etc/inputrc, където формата е "combination": command. Другия е да сложите в $HOME/.zshrc bindkey "combination" command. Обърнете внимание, че комбинацията се задава в двойни кавички.

Arduino + Arch

Наскоро подкарах Arduino UNO ver3 на ArchLinux-а върху лаптопа, затова ще споделя с 2 думи как става понеже е нетривиално.

1. Инсталирате си arduino пакета от aur (версия 1:1.0-3 при мен)
2. Създавате си директория, с името на проекта (да речем blink) и вътре в нея основния файл (blink.ino -- basename трябва да съвпада с директорията)
3. Сваляте си arduino-cmake в директорията на проекта (поддиректория arduino-cmake, ако ползвате gitiпрепоръчително е със submodule)
4. Създавате CMakeLists.txt файл във blink със следното съдържание:

   set(CMAKE_TOOLCHAIN_FILE ${CMAKE_SOURCE_DIR}/arduino-cmake/cmake/ArduinoToolchain.cmake)
   
   cmake_minimum_required(VERSION 2.8)
   project(Blink C CXX)
   
   print_board_list()
   print_programmer_list()
   
   generate_arduino_firmware(blink
       SKETCH ${CMAKE_SOURCE_DIR}
       BOARD uno
       PORT /dev/ttyACM0
       PROGRAMMER usbtinyisp
       AFLAGS -V
       NO_AUTOLIBS)

5. $ mkdir build
   $ cd build
   $ cmake ..
   $ make
   $ make blink-upload

Ако ползвате друго ардуино може да се наложи да смените BOARD, и/или PORT. За второто може да проверите със ls /dev/ttyACM* /dev/ttyUSB* за да разберете как точно се казва устройството на вашата машина (след като сте закачили arduino-то естествено).

Ако съм пропуснал нещо, пишете да го фиксна ;-)

Act 4 ACTA

Ако сте чували за SOPA и PIPA (популярно главно в САЩ), то ACTA може да се нарече техен еквивалент в ЕС.

За да се запознаете по-добре гледайте:


След което може да прочетете какво казват по въпроса Григор Гачев, Йордан Юруков, Нели Огнянова.

Накрая може да дойдете на протеста по случая - 11:00 часа на 11 февруари, НДК.

Междувременно докато чакате да дойде протеста може да метнете едно писмо до евродепутатите.

До момента съм получил положителен отговор от Евгени Кирилов. Следващия път като гласувате за евродепутати да го имате предвид!

Code retreat #3

На 3ти декември се проведе Code Retreat #3.

Събрахме се 20тина души на различно ниво, с основната идея да се осъвършенстваме като програмисти. За повечето TDD беше нова концепция, така че основния фокус беше върху нейното овладяване.

Ще опиша накратко какво научих от срещата:

• Тестването е хубаво нещо. Ако имате възможност - правете го. Не че не го знаех това и преди, но сега е по-затвърдено :)
• Тестовете са идеалния начин да се рефакторира кода. Причината е, че при наличие на тестове сме малко по-спокойни и сме готови да направим по-големи промени на кода.
• Писането на fake-ове, с други думи код, който не е верен в общия случай, но прави така, че тестовете да минават, е установена практика. До колко съм съгласен с нея още не знам :)
• TDD не е сребърен куршум. Според мен трябва да се използва с мярка. Понякога влагането на малко повече време в началото за взимане на важни дизайнерски решения ще се отплати многократно по-късно. Това, че TDD се фокусира върху конкретното следващото нещо, което трябва да се имплементира, и това по някакъв начин ни успокоява, защото имаме да мислим за малко неща е хубаво, но според мен е твърде силно опростяване.
• Тестовете са хубав начин за комуникация. Може би много по-добър от вербалната комуникация, защото 1) стоят в репозиторито и 2) могат да бъдат изпълнени. Ако има възможност да се генерира документация и примери от тестове аз съм "за" с 2 ръце. Също - ако може да се намали изпращането на мейли, чатове и вербална комуникация между членовете на един екип за сметка на повече и по ясни тестове, "за" съм с 3 ръце :)

В заключение, TDD е малко или много свързано с писане на тестове. Ако имате удобен начин да пишете тестове не ви коства много да пробвате TDD. Проблема в момента е, че практиката да се пишат тестове не е добре улегнала в повечето проекти, и ако решите да пишете patch за проект, който не ползва тестове, шансовете са че и вие няма да напишете тест, защото първоначалното усилие по изграждането на условия за тестване не е малко. От друга страна ако проекта ползва тестове, то направо е престъпление да го допълвате, без да пишете тестове към него, даже в някои случаи няма да ви позволят.

Така че, ако имате възможност да пишете тестове -- пробвайте TDD. Ако не, поне се старайте новите проекти в които участвате да имат изградена система за тестване, и ползвайте TDD в тях :) Ако TDD не ви харесва, нека това не подбива мнението ви за тестването по принцип.