Jogger.pl


Techblog jest moderowaną częścią serwisu Jogger.pl na której pojawiają się najciekawsze wpisy.

Najnowsze wpisy RSS

Kilka miesięcy temu pytałem #django-wców na blipie o możliwość wstawiania do treści słów kluczowych, które później byłyby zamieniane na różne dziwne rzeczy. Nikt mi wtedy nie odpowiedział, więc pewnie sprawa nie jest jeszcze zbyt popularna. Ostatnio jednak znalazłem rozwiązanie mojego problemu. Słowo klucz - (...)

Jest sobie boost (1.33.1), bierzemy czas z posix_time:microsec_clock, a program ANI RAZU nie wywołuje gettimeofday czy jakiegokolwiek podobnej funkcji. No to skąd bierze czas?!? Dla niedowiarków mam strace'a.

Postanowiłem udostępnić w postaci kodu źródłowego mój projekt na zaliczenie „proceduralnych języków programowania II”, czyli program w C z użyciem niestandardowych bibliotek. Jest to prosta aplikacja sieciowa klient-serwer umożliwiająca komunikację tekstową w czasie rzeczywistym oraz prymitywną archiwizację wiadomości. Szczegółowa dokumentacja w pliku znajdującym się w archiwum (pdf + źródła), które można pobrać klikając tutaj lub svn.

(...)

Na wzór podświetlania składni dla slapd.conf, napisałem podświetlanie dla postfiksowych map LDAP: http://dozzie.jarowit.net/jogger/pfldap/pfldap.vim.

Podobnie jak w poprzednim wpisie, jeszcze nie opublikowałem skryptu na www.vim.org, bo czegoś mu brakuje (choć niedużo: jedynie obsługi porównań bardziej skomplikowanych niż mail=foo@* w zapytaniu LDAP).

Przykładowa składnia (choć na jarowicie akurat używam Exima, nie Postfiksa):
[img]

Od dość dawna mnie uwierało, że nie ma podświetlania składni dla slapd.conf (plik konfiguracyjny OpenLDAP). W końcu się wkurzyłem i napisałem własne reguły, a w każdym razie ich większość: http://dozzie.jarowit.net/jogger/slapd/slapd.vim.

Te reguły są całkiem używalne, ale brakuje im paru rzeczy. Do tego czasu nie chcę ich publikować na www.vim.org.

Przede wszystkim chcę jeszcze dorobić specjalne podświetlanie niektórych ważnych parametrów w definicjach database (np. rootdn czy suffix), a dyrektywy limit, ldapsyntax i ditcontentrule nie otrzymują żadnego specjalnego traktowania ponad podświetlenie nazwy dyrektywy. Za to ładnie się wyświetlają definicje uprawnień (access to ...) i schemy (attributetype i objectclass).

Przykłady podświetlania (argument rootpw został zmieniony na losowy):
[img]
[img]
[img]

Po Eloquent Ruby Russa Olsena sporo sobie obecywałem, może nawet trochę za wiele. Czy jestem zawiedziony? Chyba trochę tak. Ale z drugiej strony ciężko pewnie o książkę o Ruby, która mogłaby zaskoczyć programistę z pięcioletnim doświadczeniem. Chociaż Eloquent Ruby w pewnych miejscach był zaskakujący i bardzo ciekawy (rozdziały o operatorach). Czasami miałem pretensje o autora, że opisuje kompletne podstawy. Czemu każda książka o Ruby musi opisywać takie rzeczy jak if, until, while? Autor chyba mógł załóżyć, czytający zna chociaż podstawy Rubiego. Zastanawiające jest to, że w poprzedniej książce tego autora Design Patterns in Ruby też mi się to nie podobało.

Podsumowując całą książkę trzeba ją uznać za pozycję dobrą, nawet tak na 4+. Książka w dobry sposób pokazuje niektóre bardziej 'magiczne' aspekty języka. Kolejna książka, która bardzo dużo może zaoferować komuś kto już zna Rubiego, ale nie ma jeszcze dużego doświadczenia.

Zagadka w stylu: to nie powinno działać. W plikach konfiguracyjnych nie ma ustawionego routingu, router nie odpowiada na ICM Router Discovery, a mimo to routing (netstat -r) jest ustawiony. JAK? Gdzieś jeszcze domyślnie (oprócz /etc/defaultrouter) jest konfigurowane? in.rdisc odpytuje po DHCP? Ki czort?

Słowem wstępu - wiem, LESS to nic nowego, ale jak już pisałem wcześniej chcę pisać tylko o tym, czego sam używam i co mogę z czystym sumieniem polecić.

CSS i jego niedoskonałości

Każdy kto para się webdeveloperką wie co to CSS i chociażby standard 2.0 ma w małym palcu. Jeżeli tak, to doskonale też wie, czego w CSS brakuje - zagnieżdżania reguł, możliwości definiowania zmiennych, możliwości wykorzystywania tego samego kodu w wielu miejscach etc. Jak wiadomo - przyroda nie toleruje pustki, na skutek czego powstawały rozwiązania pozwalające na stosowanie w/w rozwiązań - działające zarówno po stronie serwera (np. stosowanie plików PHP do generowania CSS) lub po stronie klienta (wykonane w JS).

Światełko w tunelu - LESS

Aktualnie najpopularniejszym rozwiązaniem z grupy tych drugich jest LESS. Jego stosowanie ogranicza się do zmiany nazwy arkusza stylów z .css na .less oraz dodanie samej biblioteki do strony. Po tych zabiegach możemy korzystać już z pełnych dobrodziejstw, jakie oferuje skrypt. Popularną alternatywą jest SASS. Oba z tych języków są bardzo podobne zarówno pod wzg. możliwości jak i składni, więc wybór sprowadza się do osobistych (...)

Obiecywałem sobie, że napiszę piękny, duży artykuł o cfengine, który będzie wprowadzać czytelnika do wszystkiego: do składni reguł (CFE 2.x), do narzędzi, których używam, do sposobów pracy, a nawet będzie służył za cfengine cheat sheet. Dupa, raczej nic z tego nie wyjdzie. Jestem zbyt leniwy.

W zamian za to stworzę parę mniejszych artykułów. Coś na wzór pisania na wiki: najpierw szkic artykułu, a potem po jednej, po dwie informacje. Małe przyrostowe edycje są zawsze łatwiejsze w przeprowadzeniu niż jeden big bang. Dziś chciałem przede wszystkim pokazać mój model pracy.

Przy czterech setkach serwerów wiadomo, że potrzebny jest jakiś system automatyzacji pracy. Na rynku jest wiele różnych, z których niektóre opierają się na jednoczesnej pracy -- mniej lub bardziej interaktywnej -- na wielu serwerach (ClusterSSH, PSSH, Pdsh), inne na wysyłaniu skryptów na serwery docelowe (

Last time I've determined that the biggest problem of make and waf was a big dependency graph. To verify that, I prepared an even bigger project to test. Results follow but first, I've got some news.

Tup is another build tool. But not yet another. Mike Shal, the author of Tup, used a completely different approach to the build problem and have reverted the dependency graph. This way the algorithm starts with changed nodes and builds the graph by adding their dependencies (in this case, the products). This results in a much smaller graph to solve. I read the results from the page and they're stunning.

There are few things I like about Tup. The inverted graph is a good idea. Who cares how to build program foo. If a source file changed, and this source file is there probably not for fun, then compile it. That's what incremental build is all about. Another nice feature is an implicit handling of subdirectories (note, it's not recursion, just splitting the build files). If you want to add a subdirectory, just put a Tup-file here, no need to mention that in the parent.

Another interesting idea is the way that dependencies are handled. Tup monitors applications run during build and if those apps access filesystem, is sees that and adds that info to its database. No need to process #include files anymore. If gcc opens them, it meens they're needed. And it works for all types of files.

What I don't like about tup... first of all, yet another syntax to learn. I really agree with Waf, Scons and others, that using an existing language is better. Second thing is that it needs fuse. My current kernel has no fuse support so right now I'm not able to test tup myself.

A bigger problem is that it is so damn small. I like small things, don't get me wrong. But from a build tool, I would expect support for some common usage patterns like build variants, unit tests, configuration, etc. I like Waf's way of expressing the build process in terms of tasks generators, i.e. gimme a program built from these sources, instead of node-center view that tup, make and many others use. Compile first source, compile another source, link. Crap. Every C++ program is built basically the same way. Don't repeat yourself.

Tup implements some functionality to monitor filesystem, for exapmle it cleans unused build files (e.g. when you rename output, the old file is now unused) automatically. I haven't used it yet, I'm not sure if I like it or not.

OK, back to Waf and Make. It's now clear that they both suck, let's just see how. The project was bigger this time:

  • 9100 files
  • 300 MB of code
  • 30487 includes in .cpp files
  • 15727 includes in .h files

Yesterday I dig into waf's code, I've also payed a little more attention to the first build, because it turned out to be a hint of what's going on. Make sucks at finding the proper build order, but it's damn fast on checking the files. Git does exactly the opposite. Why? Because Git uses domain knowledge to its aid when ordering tasks. In simpler (and not entirely true) words, it just knows that you first need to compile sources, then link.

The observed behavior is that, before actually doing anything, make takes the same amount of time for the first build and for an incremental build. Every time it is run, it checks dates on all files and determines the order. Waf starts almost immediately (just some lag caused (...)

I don't post in English but since I couldn't google this, I've decided to share the results in a common language. Since the Waf's community is quite small, it seemed almost pointless to write in Polish.

Waf is a promising build tool. It uses checksums to determine if anything needs updating. I like this feature because when working with Git and switching branches back and forth, I often get different timestamps for files that didn't really change.

The problem with checksums is that it takes some time to compute them, so GNU Make, in theory, could be faster here... I decided to check that. The aim was to measure how long it takes to determine that nothing changed and nothing needs to be rebuilt.

I've generated a sample C++ project. The generator was extremely stupid. I've played a little with parameters: number of files, their size and number of #include statements in the generated code. After some tuning to get enough files for the build to take some time, but not forever, I got a project with:

  • 6300 files (3150 cpp, 3150 h)
  • 210 MB of code
  • 21525 includes in .cpp files
  • 10917 includes in .h files

Note: kids, use the pimpl idiom and all that stuff to reduce the number of #includes in your code. It takes forever (an hour on my PC) to compile a project that contains nothing but comments and #include statements. To get a somehow realistic dependency graph I decided that all headers will only include from the set of first 50 headers and implementation files can include from anything.

When the project was ready, I've generated different sets of build files.

First a standard makefile (marked (1) below) in a style I would write manually, i.e. using variables, %.o: %.cpp and all that stuff. It was a single file, no recursion. Dependencies for .o and .so files were listed explicitly, dependencies between headers were generated using g++ -MMD and included. Makefile had 480 lines.

Another makefile (2) was not using variables (except for $@ and $^ in the recipes) but instead it was listing all dependencies and recipes explicitly. The dependencies on included files were generated as before. Over 15900 lines.

Waf scripts were exactly how you would expect them, every task generator got its target's name and a list of sources. Nothing fancy. I've only played with the function responsible for calculating checksums. In the first case (3) it was the standard implementation that calculated md5 of file's content. Then I've tried to get rid of md5s by using just timestamp and I've also tried the md5_tmstamp extension. This extension tries to get the best of two worlds by updating the checksum only if the timestamp changed. Results were very close so I'm showing only the timestamp-based version (4).

  • GNU Make variables (1): 9.777 s (...)

Wstęp
Moja przygoda z pythonem rozpoczęła się stosunkowo niedawno - kilka tygodni temu przy okazji tworzenia nowej wersji dloadera, wcześniej moje kontakty z tym językiem były raczej sporadyczne. Zanim zacząłem mój romans z pythonem, przeczytałem kilka wpisów na blogach osób starających się porównać języki które wymieniłem w tytule pod względem przydatności do tworzenia stron internetowych, niestety troszkę się zawiodłem. Większość ludzi, jak wynika z moich prywatnych obserwacji, porównuje Django z PHP co jest rażącym błędem. Nie widzę dobrego sposobu, a nawet sensu, porównywania frameworka z językiem programowania. Postaram się w obiektywny sposób przedstawić oba te języki, nie omieszkam również sięgnąć w stronę najpopularniejszych frameworków.

Popularność
W tej kategorii PHP jest niekwestionowanym zwycięzcą, według TIOBE(stan ze stycznia bieżącego roku) PHP jest na 6 miejscu, natomiast Python na 8. Ranking o którym wspomniałem dostępny jest na

Ostatnio przemigrowałem z tgt na nowy, lepszy, wbudowany w jądro LIO. Chodzi o cel SCSI. Po robocie odsunąłem się od monitorów, spojrzałem na stary config, spojrzałem na nowy i naszła mnie refleksja.

Czy przejście z takiego sposobu konfigurowania:

vendor_id UTC FS Support
product_id Linux iSCSI

# Set the driver. If not specified, defaults to "iscsi".

default-driver iscsi

<target iqn.2010-08.com.fs.utc:dvdtmp>
        backing-store /dev/mapper/sabretoothvg-iscsi.dvdtmp
</target>

<target iqn.2010-08.com.utc.fs:winxppp45client-stor1>
        backing-store /dev/sabretoothvg/iscsi.winxppp45client-stor1
</target>

<target (...)
  • HP AllianceONE, wypełniam te kretyńskie formularze z firmy Dilberta rodem, pół tuzina razy wpisuję swoje nazwisko, klnę, wymyślam ad-hoc jaki to właściwie produkt mam niby robić na ich systemach (a skąd mam wiedzieć, że się nadają do czegokolwiek?), "przyjęliśmy Pańską aplikację i cisza".
  • Dystrybutor: "oj, nie wiem, Itanium, nie słyszałam o takim procesorze... sam system? Nie prowadzimy sprzedaży".

Sam nie pochwalam zaśmiecania techbloga, ale #drogijoggerze pomóż, bom zdesperowany do takiego stopnia, że zaczynam dodawać słówko "torrent" do guglarki.


Przeglądaj strony: