First precompile assets locally, by runnung

rake assets:precompile

I noticed that assets precompilation is allways in production env. You may assure that by running RAKE_ENV=production.

But that makes some problems on your local machine, since your app loads now both dynamic AND precompiled assets. You may notice that, when you have two ajax requests on one click running. What you need to do is adding this option to your environments/develomplent.rb:

  config.serve_static_assets = false

But be carefull if you use Thin server – it seems to ignore that one.

And please remember clear out web browser cache. And you should be good to go.

But you need to precompile assets manually and commit changes to repo before each deployment. That sucks, but the alternative is you siting there and waiting for miracle, and your work is not going forward. Which one sucks more for you?

photo: photography-andreas

Gmail się obraził i chciał, żeby aplikacja rozwiązywała captche, a SendGrid się weryfikuje ręcznie. Jednak reset hasła nie może tak po prostu nie działać. Dobrze, że jest na kogo liczyć w dzisiejszych czasach.

ps. jeśli nie zarejestrowaliście się do tej pory na http://naveg.as/ to musicie się teraz uzbroić nieco w cierpliwość – od teraz będzie dostępba tylko poprzez zaproszenia. Nadchodzi czas intensywnych beta testów :P

Jak myślicie jaka jest odpowiedź? (Oprócz tej, że powinien przeczytać książkę/dwie?).

Tutaj przeczytacie najciekawszą i bardzo obrazową odpowiedź dlaczego tak się dzieje (po angielsku). Pokażcie ją swojemu “menadżerowi” jeśli też go ta kwestia dziwi.

Moja odpowiedź: Estymacja jest błędna z defininicji (<łac. aestimatio ocena> != wycena). Jeśli zakładasz, ze estymacja da Ci dokładny wynik, to zamień to słowo na szacowanie. Jeśli nadal popełniasz ten sam błąd i po szacowaniu spodziewasz się dokładnych wyników – zamień to słowo na… zgadywanie. Czasem trafi się ktoś, kto potrzebuje jeszcze silniejszego określenia, żeby odpaliło odpowiednie zwoje mózgowe. Ja w ekstremalnych warunkach lubię użyć określenia “Wróżenie z fusów”.

foto: Flood

Szczególnie, jeśli na przeciw masz zabójczą kombinację:

zabójca kombinacja =
rozległe zadanie
+ technologia w której brak Ci doświadczenia
+ menadżer (lub klient) który nie rozumie znaczenia słów

• “To wróżenie z fusów”.
• “Jeśli mam podać konkretne daty, to zajmie od 3 do 10 miesięcy”
• “Dlaczego? Bo to jest jak wróżenie z fusów”
• “Jest wiele niewiadomych, a wymagań jest na tyle dużo, że nie mieszczą się już na kartce a4 – dlatego przypomina to wróżenie z fusów”.
• “Podając Ci konkretne wartości, czuję się jakbym wróżył z fusów”

Powtarzaj to tak często jak potrafisz. I porzuć nadzieję, że zrozumieją. Będziesz powtarzał to zdanie (lub inne ulubione) tylko z jednego powodu – dla zachowania własnego zdrowia psychicznego. Gdy na kolejnym spotkaniu (miejmy nadzieję, że szybciej niż za 3 miesiące) ktoś wytknie Ci nietrafioną estymację przypomnij mu o tym. Powtórzyłeś tę frazę tak wiele razy, że coś musi zaświtać… Estymacje to wróżenie z fusów.

Estymacja z definicji zawiera błąd. Istotne jest jaka jest natura tego błędu.

Dlatego jest nadzieja. W pytaniu jest informacja, że estymacje zazwyczaj chybią o współczynnik 2-3 (cokolwiek by to nie znaczyło). I to jest już coś na czym można budować. Zwinne metodyki potrafią radzić sobie z błędnymi estymacjami jeśli błąd jest w miarę stały (i nie trzeba nawet wiedzieć ile on wynosi). Ale to temat na kolejny post.

foto: Wen Rou

Phing creates file phing.bat in the PHP directory, so it makes only to put another file, named phing (executable) with content:

php -d html_errors=off -qC "C:\path_to_your\PHP\PEAR\phing.php" $@

And that’s it. Hope it was helpful :)

Dziś na hacking.pl pojawił się artykuł potwierdzający, że poniekąd miałem rację. Nawet wychodzi na to, że użyta przeze mnie sugestia o trzymaniu ich w piwnicy nie była aż tak odległa od prawdy ;)

Z innej beczki – dlaczego hacking.pl nie potrafi podać aktywnego linka do źródła, tylko podaje nieaktywny tekst z adresem do strony głównej źródłowego serwisu? Styl podobny jak webinside, ale ten drugi nie podaje nic. Udaje, że jest sam w całym Internecie…

Jesteś kompletnie zielony, więc cykl pracy wygląda mniej więcej tak:

1. nowy problem
2. google
3. znajdujesz tutorial (lub odpowiedź na stack-overflow), który go (lub wystarczająco podobny) rozwiązuje
4. implementujesz rozwiązanie zgodnie z tekstem
5. dostosowujesz do swoich potrzeb
6. powtarzasz cykl

Po pewnym czasie listę można zredukować o punkt 4 – od razu przystępujemy do modyfikacji. Po kolejnych cyklach pomijamy punkt 2 i wiemy, że analogie są w napisanym przez nas kodzie- musimy sobie przypomnieć “jak to się robiło”. Coraz mniej też jest problemów, które w ten sposób potrzebujemy rozwiązać aż w końcu sięgamy po tą technikę tak rzadko, że już nie można mówić o Tutorial Driven Development. Czujemy się swobodnie z nową technologią, a z tąd już prosta (choć długa) droga do zostania ekspertem.

foto: Sigurd R

Ps. Ten wpis miał być humorystyczny, ale w trakcie pisania uświadomiłem sobie, że opisuję koncepcję Shu-ha-ri).

Real-Worls Solutions for Developing High Quality PHP Frameworks and Applications

• pracuje na systemach z zaszłościami (Legacy Systems)
• myśli, że refaktoring takich systemów nie jest możliwy
• testy automatyczne muszą być równie przyjemne jak hemoroidy
• boi się, że aplikacja, w którą zainwestował już sporo powoli staje się niemożliwa w utrzymaniu
• myśli, że system, którego używa od lat trzeba przepisać od zera

Pozycja zdecudowanie nie jest przeznaczona dla tych, którzy zaczynają swoją przygodę z PHP. Jeśli jednak już okrzepłeś i szukasz czegoś więcej – polecam gorąco.