Do napisania poprzedniego wpisu „zainspirował” mnie błąd pojawiający się przy próbie uruchomienia rtorrent‚a:

rtorrent: symbol lookup error: rtorrent: undefined symbol: _ZN7torrent10ThreadBase8m_globalE

Błąd pojawił się po przerwanej aktualizacji zainstalowanych pakietów. Trop do dokończenia aktualizacji prowadził donikąd.

Przeszukawszy internet – wszyscy rozpisują się o brakujących plikach konfiguracyjnych .rtorrent.rc, niestety ten trop już z góry był porażką.

Lecz na jednej znalezionej stronie pewien użytkownik odpisywał na podobny problem z prośbą o hash’a md5 libtorrent‚a, informacja wprawdzie przeterminowana, bo dotyczyła znacznie starszej wersji, ale dlaczego nie spróbować?

tail -n 100 /var/log/yum.log

No i mamy:

Jun 12 22:18:44 Updated: libtorrent-0.13.2-1.el5.rf.i386

Może więc coś jest nie tak z tym libtorrent’em? Wszystko by na to wskazywało, no cóż. Spróbujmy!

yum downgrade libtorrent

I to był strzał w dziesiątkę 🙂
Co prawda rozwiązaliśmy problem, rtorrent znowu działa prawidłowo, ale niestety nie wiemy czym ów problem był spowodowany.

Generalnie nie ma problemu ze znalezieniem jakiegoś poradnika dotyczącego instalacji SVN’a na linuxie.

Najwięcej jest tych które działają wraz z Apachem. I o ile jest to fajne (do czasu), o tyle przy większych projektach niestety Apache wymięka (zwłaszcza na słabszych, lub bardziej dociążonych maszynach).

Poza tym dostęp przez np. tortoiseSVN do takiego serwera przez protokół http:// to trochę jakby jazda naokoło.

(Początkowo w swoich projektach korzystałem z tej pierwszej wersji – łatwy dostęp przez port 80 ma swoje zalety, niemniej przy większych projektach, bądź cięższych plikach zaczęły pojawiać się problemy wręcz uniemożliwiające pobranie projektu przy użyciu klienta SVN’a).

Jest jeden mały problemik – praktycznie wszystkie tutoriale o SVN’ie kończą się czymś takim:

svnserve -d -r /home/svn/repositories 

No i super, uruchomimy sobie daemona i wszystko będzie nam ładnie śmigać, aż do restartu maszyny :-]
Aby temu zaradzić wystarczy w pliku:  /etc/rc.d/rc.local
Dopisać w/w komendę:   svnserve -d -r /home/svn/repositories

I od teraz SVN „wstanie” przy każdym uruchomieniu serwera 🙂

Jeżeli instalujesz skrypt reCaptcha na swojej stronie możesz być zainteresowany polską wersją językową modułu.

Zgodnie z instrukcją „producenta” oraz moją propozycją tłumaczenia, aby to wykonać musisz jedynie przed kodem JavaScript samej Captchy w opcjach dodać parametr custom_translations zawierający tłumaczenie:

var RecaptchaOptions = {
custom_translations : {
instructions_visual : „Przepisz kod z obrazka:”,
instructions_audio : „Wpisz usłyszany kod”,
play_again : „Odtwórz ponownie”,
cant_hear_this : „Pobierz kod jako MP3”,
visual_challenge : „Pokaż obrazek”,
audio_challenge : „Odsłuchaj kod”,
refresh_btn : „Pobierz nowy kod”,
help_btn : „Pomoc”,
incorrect_try_again : „Kod nieprawidłowy! Spróbuj ponownie”
}
};

Podczas przenoszenia strony www opartej o WordPress, gdy wszystko wydawało się byćw porządku otrzymałem następujący komunikat o błędzie:

Nie posiadasz wystarczających uprawnień, by wejść na tę stronę.

Było to wynikiem zmiany prefixów w nazwach tabel  z wp_ na xx_

Aby WordPress zadziałał po zmianie prefixów (zmiana nazw tabel oraz zmiana w pliku konfiguracyjnym), konieczne jest jeszcze wprowadzenie następujących poprawek (wszystko w bazy danych):

Rozwiązanie:

SELECT * FROM xx_usermeta x;
następujące wiersze:
wp_capabilities
wp_user_level
wp_dashboard_quick_press_last_post_id

zmieniamy na:

xx_capabilities
xx_user_level
xx_dashboard_quick_press_last_post_id

Powtarzamy w/w operację dla kolejnej tabeli:

SELECT * FROM wp_en_options
wp_user_roles

zmianiamy na

xx_user_roles

Pytanie z którym boryka się każdy Webdeveloper.

Pracując jako Kontroler Jakości Oprogramowania w pewnej zagranicznej firmie praca odbywała się na „konkretnej maszynie” z dużym monitorem gdzie spod Debiana odpalało się kilka instancji systemu Windows z różnymi przeglądarkami. W ten sposób można było jednocześnie kontrolować różne środowiska pracy. O ile tam mogliśmy sobie na to pozwolić, o tyle w warunkach domowych może to być trochę trudne, a przynajmniej uciążliwe (chociażby ze względu na konieczność tworzenia kilku maszyn wirtualnych – majstrowanie czas, a jak coś nie idzie po naszej myśli, to tracimy go znacznie więcej).

Świetną alternatywą są serwisy WWW które renderują za nas stronę a nam pokazują jedynie efekt końcowy w postaci obrazka. Co prawda nie zobaczymy tam wszystkiego (np. ew. błędów JavaScript), ale jest to niezła alternatywa. Przykład takiego serwisu (darmowego): http://ipinfo.info/netrenderer/index.php

IETester

IETester

Kolejnym sposobem jest zainstalowanie programu IETester: http://www.my-debugbar.com/wiki/IETester/HomePage, który pozwoli nam na jednoczesne uruchomienie w oddzielnych kartach silników różnych wersji Internet Explorer’a i umożliwi dokładne sprawdzenie poprawności wyświetlania i działania strony. Warto w tym miejscu zaznaczyć, że 12% rynku to wciąż Internet Explorer 6.

 

, , ,

Ostatnio natknąłem się na problem wyboru odpowiedniego oskryptowania dla sklepu internetowego.

Na rynku jest tyle firm zajmujących się tą tematyką, tyle skryptów, płatnych, bezpłatnych – wydawać by się mogło „jest w czym wybierać” – na pewno coś znajdę. W rzeczywistości okazało się, że nie ma idealnie pasującego do moich potrzeb rozwiązania i trzeba iść na pewne kompromisy.

Wyróżniamy 3 główne rodzaje oprogramowania / licencjonowania / opłat:

  1. Model licencyjny (płacimy raz – używamy cały czas)
  2. Model abonamentowy (płacimy abonament za użytkowanie skryptu)
  3. Model prowizyjny (płacimy prowizję od sprzedaży)

Każdy model ma swoje wady i zalety, dla mnie dwa ostatnie w ogóle nie wchodzą w grę! O ile zgodzę się z opłatą za pomoc techniczną i opiekę nad sklepem, to dzierżawa skryptu? Wynajem oprogramowania?
Co to ma być?!

Chociaż jest w tym sporo racji, jeżeli firma tworzy oprogramowanie – to wszystko kosztuje, zazwyczaj taki sklep – dobry sklep, to dość długi proces tworzenia, potem łatanie bug’ów, które praktycznie zawsze gdzieś są. Jak zwykli mawiać testerzy (Kontrolerzy Jakości Oprogramowania): Nie ma bezbłędnego oprogramowania – są tylko niedokładnie przetestowane.
Tak więc cały ten proces to koszty – duże koszty. Firma musi zarabiać, sprzedając licencję właściwie widzi klienta tylko raz i tyle było dobrego, trzeba szukać następnego. W modelu abonamentowym jest już lepiej – raz złapiemy klienta, przychód mamy cały czas. Oprogramowania abonamentowe i prowizyjne instalowane jest na serwerach firmy, więc kupujący nie ma do nich dostępu, więc w tym przypadku firma zarabia dokładnie wtedy kiedy ma jakieś koszty (nie licząc procesu tworzenia oprogramowani) i przestaje zarabiać na danym kliencie, gdy ten przestaje generować koszt utrzymania jego sklepu.

Tak więc wracając do tematu, modele prowizyjny i abonamentowy są „logiczne” z punktu widzenia firmy. Ba! Są bardzo atrakcyjne z ich punktu widzenia. Od strony klienta, też, choć ja takim klientem z pewnością nie jestem.
Jakie to korzyści? Przez cały czas trwania umowy (czyli przez cały czas gdy płacimy) – dostęp do pomocy technicznej, brak problemów z aktualizacjami, właściwie, to nic nas nie obchodzi – tylko płacimy i wymagamy. Teoretycznie opłaty abonamentowe powinny być takie, aby spokojnie można było odpalić własny biznesik, bez pakowania się w koszty kupna i instalacji oprogramowania.
Ale… tutaj bardzo często nie jest to stały abonament – w przypadku modelu abonamentowego opłata rośnie wraz ze wzrostem produktów, bądź częściej, wraz ze wzrostem ilości odwiedzin. Więc „mamy jak w banku”, że im nasz sklepik będzie lepszy (będzie się rozrastał), tym trzeba będzie płacić więcej; w modelu prowizyjnym – sprawa jasna, wystarczy popatrzyć na Allegro (im więcej sprzedaje, tym więcej płacę).

Podsumowując trochę nieskładny tekst:

Zalety modeli abonamentowych / prowizyjnych:

  • brak kosztów na starcie
  • pomoc techniczna
  • nie martwimy się serwerem (a czasem i domeną – choć tym polecałbym się jednak pomartwić :P)
  • płacimy proporcjonalnie (teoretycznie) do tego co zarabiamy

Wady…

  • brak kontroli nad oprogramowaniem (nie ma możliwości dopasowania go do siebie / do swojego sklepu)
  • stałe (cały czas płacimy) wydatki na utrzymanie sklepu

Zalety modelu licencyjnego:

  • Mamy oprogramowanie „na własność” – zazwyczaj autor umożliwia nam modyfikację i dostosowywanie sklepu (modyfikację kodu) do swoich potrzeb
  • Jednorazowa opłata

Wady:

  • Zazwyczaj duży koszt licencji
  • Brak pomocy technicznej

Eeesz… rozpisałem się, próbując opisać wszystko a tak naprawdę mija się to z celem, chciałem tylko opisać jak wyglądał wybór oprogramowania w moim wypadku, a nie rozłazić się po innych wątkach {zaraz się poprawi całość :-)}

Co mnie interesowało:

  • Kupno oprogramowania – takiego, które sam sobie zainstaluję, będę miał możliwość modyfikacji kodu – dostosowania go pod siebie. Mam kilka pomysłów i najzwyczajniej chciałbym pogrzebać w kodzie i „zoptymalizować” go pod swoim kątem.
  • Integracja z polskimi porównywarkami cen i systemami płatności. Szybkie płatności on-line to już niemal standard (PayPal odpada – co z tego, że globalny, jak mały odsetek polaków go używa). Porównywarki cen dają mi możliwość konkurowania z innymi.
  • Możliwość dostosowania szablonu graficznego
  • Nie mam czasu pisać dedykowane oprogramowanie, ani nie chcę kupować licencji za kilka tysięcy