« September 2009 | Main | November 2009 »
Posted at 02:22 AM in Android, Moje oprogramowanie, Programowanie Google Android | Permalink
DO NIEZWŁOCZNEJ PUBLIKACJI:
Kontakt:
Paul Stevens
devGuide.net
http://devguide.net/software/iphone/denoizr
Londyn, Wielka Brytania, Oct 21, 2009 - firma devGuide.net ma przyjemność poinformować o publikacji pierwszej wersji aplikacji szkoleniowej deNozir dla urządzeń Apple iPhone oraz Apple iPod Touch.
deNoizr jest osobistym trenerem, którego zadaniem jest zwiększenie produktywności użytkownika przez usprawnienie procesu podejmowania decyzji. Posługując się prostym algorytmem, deNoizr pomaga użytkownikowi zdecydować czym powinien zająć się w pierwszej kolejności a co może poczekać. Jest łatwy w nauce i codziennym użytkowaniu przez co nadaje się doskonale jako wprowadzenie do metodologii Getting Things Done(tm) dla użytkowników, którym brakuje czasu na czytanie książek i udział w sesjach szkoleniowych. deNoizr jest z użytkownikiem zawsze tam gdzie jego iPhone lub iPod Touch.
deNoizr pomaga swojemu użytkownikowi zarządzać pracą oraz życiem. Jest prosty i łatwy w użyciu. Nie zniechęca użytkownika nieznanym słownictwem i skomplikowanymi systemami katalogowania kojarzonymi z wieloma metodologiami zwiększania produktywności.
Wszystko czego potrzeba aby zwiększyć swoją produktywność to aplikacja deNoizr, kalendarz, kartka papieru oraz coś do pisania.
W celu uzyskania dodatkowych informacji prosimy o kontakt z firmą devGuide.net lub odwiedzenie strony http://www.denoizr.com.
Aplikacja deNoizr jest dostępna w Apple iTunes(tm) App Store
http://itunes.com/apps/denoizr
deNoizr działa na wszystkich urządzeniach Apple iPhone / 3G / 3GS oraz na wszystkich generacjach iPod Touch działających pod kontrolą systemu iPhone OS 3.0 lub nowszego.
deNoizr będzie wkrótce dostępny na platformie Google Android oraz w postaci książkowej.
O DEVGUIDE.NET - devGuide.net jest wydawcą książek i oprogramowania. Prowadzi działalność od roku 2003.
- KONIEC -
Przykładowy ekran aplikacji deNoizr

Ikona aplikacji
![]()
deNoizr na ekranie Apple iPhone (skala 1:1)

deNoizr na ekranie Apple iPhone (skala 1:2)

deNoizr na ekranie Apple iPhone (skala 1:4)

Posted at 08:00 PM in iPhone, iPod Touch, Moje oprogramowanie, Programowanie iPhone OS | Permalink
Ogłoszona wczoraj zmiana zasad dotyczących tzw. In App Puchases (zakupów z poziomu aplikacji) w darmowych wersjach programów jest ważna z bardzo praktycznego powodu. Do tej pory, developer aplikacji płatnych chcąc opublikować aplikację darmową w wersji Lite mającej zachęcić użytkownika do zakupu wersji pełnej musiał umieszczać w katalogu App Store dwie wersje programu: pełną oraz Lite. Aby umożliwić zakup wersji pełnej musiał do wersji Lite dołączyć łącze do wersji pełnej. Tego łącza nie mógł znać dopóki w App Store nie pojawiła się wersja pełna. Z pozoru nie ma tu żadnego problemu, ale w praktyce okazywało się, że wersje Lite musiały czekać tygodniami na akceptację w App Store więc cała ta zabawa nie miała sensu i przeszkadzała developerom. Teraz będzie prościej. Użytkownik będzie mógł ściągnąć wersję darmową i jeśli spodoba mu się demo, będzie mógł zapłacić za wersję pełną i odblokować płatne funkcje aplikacji. To dobre rozwiązanie z punktu widzenia developera bo może ogranicznyć piractwo ale też użytkownika, który nie będzie musiał czyścić komputera, iPod'a i iPhone'a ze ściągniętych aplikacji w wersji Lite.
Powoli przekonuję się, że Phillip Shiller wziął sobie do serca krytykę developerów. Oby jak najszybciej znikły pozostałe przeszkody.
Posted at 10:36 AM in Programowanie iPhone OS | Permalink
Powoli dobiega proces portowania pierwszej serii naszych aplikacji z iPhone OS na Google Android. Poniżej zamieszczam kilka uwag dotyczących pracy z Android SDK na Mac OS X.
Więcej informacji opublikuję wkrótce. Obecnie czekamy na HTC Tattoo, który ma nam pomóc portować aplikacje na mniejsze ekrany. Kto wie, może HTC Tattoo nie będzie telefonem, który spodoba się 'masom'?
Posted at 10:00 AM in Programowanie Google Android | Permalink
Hop, hop! Czas na naukę nowego języka tagowania! Panie i panowie, przedstawiam Wam Augmented Reality Markup Language (ARML). Oparty o XML i OGC KML, nowy język ma szansę stać się standardem wymiany danych wykorzystywanych w aplikacjach uzupełniających rzeczywistość.
Więcej na temat ARML, na stronach projektu.
Posted at 10:00 AM in Uzupełniona rzeczywistość | Permalink
Jestem jednym z pierwszych w kolejce do obrony Apple, kiedy ktoś atakuje ich bez sensu, ale trudno mi bronić ich kiedy sami wystawiają się na krytykę i zdają się nie słuchać developerów. Tym razem chodzi oczywiście o developerów publikującyh na platformie iPhone. Nie pierwszy to raz Apple zachowuje się jak primadonna i przeszkadza innym w zarabianiu pieniędzy. Kiedyś już przegonili developerów z platformy Macintosh OS.(*) Teraz to samo powtarza się przy okazji platformy iPhone OS. Developerzy są sfrustrowani nie dlatego, że nie zarabiają milionów na swoich aplikacjach, ale dlatego, że Apple przeszkadza im zarabiać wogóle. Oto główne powody do narzekania:
Zdaję sobie sprawę, że nie wszystkie treści Apple chętnie widziałoby na swoich telefonach, ale już teraz są one dostępne przez przeglądarkę Safari, więc uciec się od tego nie da. Rozumiem, że sprawa jest bardziej skomplikowana, bo na przykład wydawcy muzyki albo Disney mogą mieć problem ze sprzedażą swoich produkcji obok pornografii czy innych treści uznawanych na 'niskie'. Kolejnym problemem jest znalezienie ludzi do kontroli takich treści. Trudno byłoby przecież znaleźć pracowników, którzy mieliby decydować o tym, która ze zgłoszonych aplikacji XXX jest dopuszczalna a która nie. Z drugiej strony ochotnicy do takiej pracy mogliby mieć subiektywne podejscie do takich treści.
Rozumiem to wszystko i staram się być wyważony w moich osądach nawet jeśli nie mogę rozpocząć marketingu zupełnie niegroźnych gier o tematyce związanej z Halloween, bo nie wiem kiedy zostaną opublikowane w App Store. Moje rozwiązanie jest proste, premiery moich aplikacji będą ukazywały się najpierw na platformie Google Android, gdzie ufa się developerom bardziej niż u Apple. Oczywiście znajdą się tacy, którzy nadużyją tego zaufania, ale wtedy ich aplikacje zostaną usunięte. Lista aplikacji, których Google nie życzy sobie w Android Market zajmuje jedną stronę formatu A4, Apple ma tych stron… (nie mogę napisać, bo tam wszystko tajne przez poufne…). I tak jest OK. Może nie idealnie, ale lepiej niż w Apple iTunes App Store, gdzie nieznany ktoś ma władzę nad wynikami mojej ciężkiej pracy. Może Android nie jest sexy, może musimy poczekać na urządzenia z procesorami 1GHz i procesorami medialnymi (Zii EGG?) aby ta platforma stała się poważną konkurencją dla iPhone OS w świecie gier, ale przynajmniej nie muszę się martwić o to, że już na samym początku ktoś chowający się za korporacyjną fasadą będzie mi odbierał możliwość zarabiania na mojej pracy.
A skoro wspomniałem już o pieniądzach… Apple płaci developerom i wydawcom po 3+ miesiącach od chwili, kiedy pobiera pieniądze od klienta, Google po… 24 godzinach. Jeżeli tylko Google nie zepsuje Android Market (a są dowody na to, że poprawia) i wyprostuje to, co krzywe w Google Checkout, developerzy pokochają Androida ze stratą dla Apple.
(*) Apple faworyzowało w latach 90-tych niektórych developerów, nie słuchało innych i niemrawo rozwijało system operacyjny, co doprowadziło do rewolty wśród developerów oraz przejście wielu z nich na platformę Microsoft Windows. Ten problem dotyczył nie tylko Apple. Jednym z mało znanych powodów, dla których np. Amiga przepadła w pomroce dziejów było faworyzowanie developerów jednego z programów do DTP do tego stopnia, że za cenę konkurowania z Macintoshem na rynku DTP Commodore wstrzymywał się przed dokonywaniem zmiany w kodzie systemu operacyjnego i ROM-ach komputerów. Działo się to w czasach przed dystrybucją aktualizacji oprogramowania przez Internet więc duzi wydawcy oprogramowania na Amigę naciskali Commodore bo musieliby wtedy wydać dużo pieniędzy na wysyłanie dyskietek z aktualizacjami. Podobne problemy miało Apple. Z jednej strony oczekiwano postępu, z drugiej nie było chętnych do ponoszenia kosztów tego postępu. Takie są skutki faworyzowania jednych developerów i ignorowania innych. Teraz to samo może się stać z ekosystemem iPhone, bo nie da się ukryć, że Apple faworyzuje niektórych developerów i wydawców, których aplikacje mają skróconą ścieżkę do App Store.
Posted at 10:00 AM in Komentarze | Permalink
(via TechCrunch) Mattel, producent m.in. Barbie proponuje klientom nową serię zabawek o nazwie Avatar. Zabawki wykorzystują uzupełnioną rzeczywistość. Dzieciaki będą mogły już niedługo odtworzyć partię szachów z Gwiezdnych Wojen?
Więcej informacji na stronie zabawek Avatar.
Posted at 10:00 AM in Uzupełniona rzeczywistość | Permalink
(via TechCrunch) Wież World Trade Center już dawno nie ma, ale ktoś, kto był tam w dniu zamachu postanowił je odtworzyć za pomocą aplikacji na iPhone.
Wikitude Augmented Reality: WTC - Its not there but its there from Wikitude on Vimeo.
Posted at 10:00 AM in Uzupełniona rzeczywistość | Permalink
Kto ze mną rozmawiał, wie że nie lubię piratów. Zawsze starałem się odnaleźć legalną ścieżkę do tego, co chciałem mieć lub robić, więc idących na skróty nie lubię. Lubię tych, którzy tworzą coś nowego, nie tych którzy cwaniakują, bo nikt ich nie złapał. Wiem, że to się nie wszystkim podoba, ale trudno--niedługo będę miał 40 lat i mam prawo zacząć zachowywać się jak stary pierdziel. Ale nie o tym dziś chcę pisać. Wręcz przeciwnie, piratom ten tekst powinien się spodobać. Bo dość mam zmuszania mnie do wyboru: woź ze sobą ciężkie książki albo bądź piratem. Coraz więcej wydawnictw udostępnia swoje publikacje w postaci elektronicznej, ale blokuje dostęp do nich osobom z Polski. To nie ma sensu, bo te same książki w postaci papierowej mogę kupić od Amazon.com… Wiem, że to są dyrdymały i większość osób po prostu sciąga sobie nielegalne kopie książek z netu, ale ja wolałbym mieć do nich oficjalny dostęp. Tak. Wiem. Czasami ciężko nie być piratem…
Posted at 10:00 AM in Komentarze | Permalink
W światku programistów istnieje nieformalny podział na programistów i programistów gier. Ci pierwsi spierają się między sobą o to, kto piękniej formatuje kod, ci drudzy nie mają oporów przed używaniem instrukcji goto, jeżeli tylko przyśpieszy to rysowanie grafiki o parę milisekund. Są od siebie różni jak żołnierze poborowi i legioniści Legii Cudzoziemskiej. Jedni narzekają na wyżywienie w stołówce, drudzy wiedzą, że kolacja czeka na nich po drugiej stronie, w bazie przeciwnika. Dlatego programiści gier rzadko przechodzą do pracy w korporacyjnych działach IT i na odwrót.
Nie piszę tego żeby gloryfikować programistów gier, ale by pomóc jednemu ze znajomych programistów, który miał problemy z kawałkiem kodu. Program działał, ale jego źródła wyglądały jak dzieła prof. Knuth'a po dywanowym nalocie bombowym. Precz poszły zasady porządnego programowania, na pole walki wkroczyły skróty i sztuczki, które już dawno przestały być wyszydzane w podręcznikach programowania, bo właściwie zniknęły w pomroce dziejów w czasach przed renesansem LISP'a. Znajomy miał problem, bo czuł, że zrobił coś złego, coś czego potem będzie żałował. Zupełnie niepotrzebnie, bo programiści gier nie stają do konkursu o palmę pierwszeństwa w przejrzystości i łatwości pielęgnacji kodu. Ich zadaniem jest stworzenie spójnego mikrokosmosu, w którym gracz będzie mógł zanurzyć się i oderwać od rzeczywistości. Nikt nie napisał jeszcze książki na temat jak to pięknie zaprogramować, bo takiej książki napisać się nie da. (Dlatego większość dobrych książek na temat programowania gier to kolekcje sprawdzonych receptur.)
Programista gier jest jak hydraulik naprawiający kanalizację w chwili gdy wszyscy na raz spuszczają wodę w toalecie--jego kod musi na śledzić stan animacji, reagować na kolizje, puszczać muzyczkę, ziać ogniem, zliczać punkty i sprawdzać, które przyciski nacisnął gracz. Często musi posługiwać się formatami zapisu dźwięku, które rozpoznaje tylko jeden układ audio na świecie albo gwałcić piękne dzieło projektantów formatu PNG i zamieniać je w zmutowanego potwora z paletą kolorów i pikselami ułożonymi w jakiś szalony sposób tylko po to, by procesor graficzny nie musiał sam dokonywać tej transformacji.
Dlatego wzorce projektowe oraz inne eleganckie rozwiązania po prostu nie sprawdzają się w świecie gier. To, co można rozwiązać w świecie korporacyjnych systemów obsługi księgowości za pomocą szybszego sprzętu jest niemożliwe do osiągnięcia w świecie gier na konsole, bo tego rodzaju sprzętu nie da się łatwo zastąpić lepszym. Programista korporacyjny może poprosić o szybszy serwer, programista gier nie może kazać graczom kupić szybszy sprzęt, bo taki zwyczajnie nie jest dostępny. Dlatego przy pisaniu gier musimy dokonywać wielu optymizacji, które nie są potrzebne w świecie korporacyjnym. A zatem nie martw się, że Twój kod jest brzydki--jeżeli działa a pamięci nie ubywa wiadrami, jest OK.

