[PL] LG GT540 "Swift" vs Samsung s5570 "Galaxy Mini". Który lepszy?

GT540 ma autofocus i większą rozdzielczość. Niestety tylko 184.2kB RAM. s5570 ma denny aparat, przyjemny ekran z kiepską rozdzielczością i 286.32kB RAM. Po zabawie nimi przez jakiś czas stwierdzam, że obydwa są cienkie. Do pracy z androidem nie ma co siadać bez minimum 512MB RAM, wewnętrznego flasha 1GB (lepiej więcej) z możliwością podpięcia wewnętrznej karty uSD, ekranu minimum(!) hVGA(320x400) koniecznie pojemnościowego (chyba, że mamy fizyczną klawiaturę). Dla tabletów oczywiście rozdzielczość większa (tablet, czyli android 3 lub nowszy... najlepiej nowszy). aGPS oraz łączność GPRS (2G... 3G też może być). Sprzętowe przyciski przynajmniej vol+,vol-,back,menu. Spust migawki bardzo pożądany. "Odrzuć" też się przydaje. I "Home". Do skanowania dokumentów i kodów QR/kreskowych koniecznie autofocus. Do robienia zdjęć autofocus się przydaje. Lampka a'la flash się przydaje do robienia zdjęć. Rozdzielczość mało znacząca (megapiksle czy cokolwiek producent wymyśli aby dużą liczbę napisać) ponieważ liczy się czułość (jasność) matrycy a dużo dużo mniej jej rozdzielczość. Kolejny telefon-zabawka jaki kupię, jeśli będzie to android, będzie posiadał zapewne: - aparat z lampą i autofocusem, 2MPix lub więcej - sprzętowych przycisków minimum 7 - RAM 1GB - wewnętrzna pamięć flash 2GB lub więcej - ekran pojemnościowy 800x480 lub więcej - aGPS a przede wszystkim będzie to telefon "do internetu" gdyż główny telefon "do dzwonienia" ma wytrzymać co najmniej tydzień bez ładowania (Nokia?)

Póki ciebie nie usłyszę... nie położę się spać...

Remona Rey - póki ciebie nie usłyszę...
Tak jakoś mi się na dobranoc wkręcił ten kawałek...

eMail verification and RFC

Yeah! Today I got another spam from prefix+suffix@gmail.com. And I was able to track the spemmer's source again. The mail is already blacklisted. Too bad that 95% of the web services hired students to create their eMail address verification (possibly the whole security !). There are (too) many pages where I cannot register eMail address that has a +. Dear WEB DEVELOPERS - it is not that difficult to read the RFC! Really! And mail address pattern [a-zA-Z0-9.]\@[a-zA-Z0-9.] is INVALID! Really!

Tam, gdzie blog adderka śpi, powstaje inny blog :)

Dzisiaj zakładam bloga dla mojego synka... zamierzam na nim zapisywać każdego dnia (ciekawe co z tego wyjdzie) przeżycia moje i synka. tombeew.blogspot.com

Against a wall... C#

Today I have realized that my knowledge about C++ and C# is almost like nothing. That counts for JAVA most probably... I've been dealing with different assemblers, shell scripts, perl scripts, a lot of PL/SQL, soma JAVA. And I have worked with ANSI C, C++, C#. And many more.
What is wrong about my skills? I have tried to use DisassembleShader code from the DIrectX. I found that there is ShaderLoader but... no disassembler ?!?
I was able to call the method directly using ImportDll, but then I am not able to work with all the fancy things that are marshaling, reflections, interoperability, unmanaged code, etc.
What I have achieved (maybe someone would find it useful) is:

[DllImport("D3dx9_24.dll" , SetLastError = true)]
// This is probably wrong to use the specific DLL instead of ex. COM GUID
private static unsafe extern IntPtr D3DXDisassembleShader(
[In]void* pShader,
[In]bool EnableColorCode,
[In]string pComments,
[return: MarshalAs(UnmanagedType.Interface)]
[Out]void* ppDisassembly
);

Now the tricky parts.
This method returns HRESULT (where C# equivalent can be IntPtr). The returned value is D3D_OK if everything went OK. D3D_OK maps to S_OK which maps to 0. Thus the expected returned value is 0.
More important piece is the ppDisassembly. This is an UnmanagedType.Interface which is in fact ID3DXBuffer (http://msdn.microsoft.com/en-us/library/bb205753(v=VS.85).aspx). It inherits from IUnknown and adds its own methods there. This is something that I don't know how to access. I have searched over the internet and this knowledge is beyond my current limits.
I think that I should use P/Invoke here, define an interface, access it. But... my knowledge is currently not enough to do this... :(

Oblivion issues

Again I have experienced some issues with my Oblivion...

1. All the dead bodies become green. Or rather all the actors became green when hit. Reason: I was missing "MMM.bsa" (AKA "Mart's Monster Mod.bsa") file. After downloading I had to ad it to the bsa list in my oblivion.ini and then it worked.
2. After start when I enter to the chamber with rats for the first time I don't see "Rusty Iron Bow" mesh. It is referenced to "weapons\MMMKOLrusty\bowrusty.nif" Cause: I've forgotten about MMM core.

Deadloop projektu, troszkę (samo)krytyki

Obserwuję od jakiegoś czasu w pracy pętlę sprzężenia zwrotnego. Trafiłem do projektu, który z różnych powodów jest opóźniony (w pół roku siłą 5 programistów wykonać 3-letnią pracę 10-ciu...). W czym problem?

Projekt się spóźnia - a przez to managerowie się denerwują i zwołują co chwila konferencje oraz wysyłają masę poczty aby być na bieżąco. A tym samym zajmują czas programistom którzy mają go coraz mniej, co z kolei zwiększa ilość konferencji i poczty...

Uważam, że z dobrą i doświadczoną 5-osobową ekipą, dobrze ustalonymi wymaganiami i architekturą, projekt można by spokojnie skończyć w rok - gdyby nie ta paskudna pętla i czynniki środowiskowe.

Na technikach agila nie znam się, lecz już na pierwszy rzut oka dostrzegam liczne zalety. Krótki okres między kolejnymi wersjami produktu, niezbyt liczna ekipa, komunikacja na bieżąco - to dużo pracy ale także lepsze jej warunki. Takie podejście jednak nie jest możliwe w mojej firmie, która kiedyś uchodziła za wzorzec.

Czego mi brakuje w moim obecnym projekcie:

• Dobrego systemu kontroli kodu / wymagań / zadań / dokumentacji - np. cvs/svn/git + mantis/itp. + google wave/gmail
• Sprawnego systemu kompilacji kodu (budowania) - np. ant / cmake
• Jednolitych procesów - czyli czegoś, co "nie opisuje jak chcielibyśmy aby cykl życia projektu mógłby wyglądać" a zamiast tego ukierunkowuje tenże cykl
• Automatycznych testów jednostkowych - np. JUnit
• Środowiska ułatwiającego programowanie i konserwację (AKA development i troubleshooting) - np. JBoss, Log4J, solidny szkielet (AKA framework)
• Możliwość dostosowania procesów i używanych technologii do tego, nad czym pracujemy - np. parsować XML z poziomu ksh/awk to na starcie pomyłka
• Kontrola procesu która zamiast obciążać pracowników pomaga im - ponieważ raportowanie co godzinę mojego statusu w 15 różnych aplikacjach oraz na dodatkowych konferencjach zabiera masę czasu
• Współpracy z innymi członkami grupy tak, aby nasza wiedza częściowo się pokrywała - a nie zarzucenie nas mnogością zadań i utrudnianie współpracy

Jakie problemy z mojej (i ogólnie programistów) strony dostrzegam:

• Projekt został spalony już na starcie, zanim jeszcze rozpoczęliśmy nad nim pracę - powinniśmy to zakwestionować na starcie
• Zgodziliśmy się na narzucenie technologii bez uważnego przestudiowania konsekwencji
• Projekt zaczynał z niedoświadczoną ekipą i nie zadbaliśmy o odpowiednie wprowadzenie wszystkich jej członków (udało się to zaledwie z dwójką)
• "Młodzi" dostali zbyt dużą kontrolę co doprowadziło do zrezygnowania z tzw. "code review"
• Zgodziliśmy się (my, członkowie z doświadczeniem) na brak tzw. "code review"
• Nie zablokowaliśmy projektu na starcie widząc, żę wymagania są bardzo niekompletne
• Zgodziliśmy się pracować z narzuconymi narzędziami, które to pamiętają czasy Gierka - choć tutaj nie mieliśmy wiele do gadania
• Nie uczestniczyliśmy w początkowych fazach tworzenia projektu - i tutaj także było to poza naszą kontrolą - co w rezultacie doprowadziło do niedoestymowania kosztów, wybrania niewłaściwych technologii i mylnego przeświadczenia kadry kierowniczej że możliwym jest "reuse" istniejącego kodu
• To, że ktoś stworzył taki paskudny kod jaki odziedziczyliśmy i że otrzymał tak odpowiedzialne zadanie jest także tragiczne - ale to również problem częściowo leżący po stronie programistów

Ech... praca w archaicznej korporacji to nie jest to co tygryski mogłyby lubić