Dzień… developera
Praktycznie od dnia pierwszego zaglądam i majstruję pod maską Mac OS X. Spróbuję w tym wpisie podsumować trochę swoje obserwacje, patrząc oczywiście z pozycji rubisty i celowo pomijając wady i dostrzeżone niedostatki :)
Pierwszą interesującą rzeczą jest środowisko developerskie dostarczane wraz z systemem (a także do pobrania za darmo ze stron Apple'a). Co prawda w czasach darmowych IDE dla Javy, nie robi to aż tak wielkiego wrażenia, ale narzędzia dla Mac OS X to nie tylko IDE. To cały komplet od IDE, przez konstruktor UI, narzędzia do podkręcania wydajności aplikacji, czy multimediów. Samo Xcode to środowisko zintegrowane bardzo silnie z system operacyjnym i jednocześnie wspierające całkiem sporo języków programowania - o czym później, oraz totalnie różne platformy docelowe (intel vs ppc). A wspomniany już Interface Builder to przyznam jedno z lepszych narzędzi do tworzenia UI z jakim miałem okazję pracować.
Drugą interesującą sprawą jest oczywiście Objective C. Większość systemu jest zaprogramowana w tym nieco egzotycznym dziś języku, który niskopoziomowości i szybkości C nadaje polotu Smalltalka. Całość dla programisty Rubiego wygląda całkiem znośnie, szczególnie, że wraz z Leopardem do użycia weszła wersja 2.0 Objective C rozszerzona m.in obsługę GC i kilka uproszczeń składni.
Jako programiści Rubiego jesteśmy przyzwyczajeni do elastyczności (duck typing) i nieskończonej wręcz rozszerzalności oprogramowania (otwarte klasy) - podobne cechy odnaleźć można w OS X. Właśnie dzięki dynamicznym cechom Objective C praktycznie każdy program można samodzielnie podrasować i nie ma to nic wspólnego z grzebaniem w asemblerze. Dobrym przykładem są tu pluginy do systemowego klienta poczty. Wszystkie bazują na dostępnie do prywatnego API programu, które wyciąga się jednym poleceniem, praktycznie z każdego programu. Tak uzyskany interfejs można wykorzystać tworząc własne rozwiązanie i to niekoniecznie już z użyciem ObjC a np. Pythona - jak? Oto przykladowy tutorial.
Kolejna sprawa to biblioteki. Mac OS X zbudowany jest z kilku głównych część/bibliotek z których największą i najważniejszą jest Cocoa. To ogromna, obiektowa biblioteka rozwiązań praktycznie dla każdego problemu z jakim stykasz się tworząc soft pod maca. Z racji rozmiarów pierwsze starcie przypomina trochę zderzenie z bibliotekami Javy - mam na myśli gargantuiczny rozmiar Cocoa. W przeciwieństwie do Javy dokumentacja dostępna na stronach Apple'a jest naprawdę bardzo dobrze przygotowana i kompletna. Praktycznie do każdego aspektu są dokumentu wprowadzające, opisujące mechanizmy wewnętrzne, sposób użycia, relacje z innymi częściami ekosystemu, często są dostępne przykładowe źródła - więc szybko można dowiedzieć się nie tylko CO (dokumentacja API) ale też DLACZEGO.
Miałem jeszcze wspomnieć o językach programowania. Wraz z systemem dostarczane są biblioteki pozwalające na korzystanie z mocy Cocoa w Pythonie i w Rubym. Co ciekawe Xcode całkiem sprawnie radzi sobie z Rubym podpowiadając metody i wskazując miejsca w dokumentacji (Pythona przyznam, nie sprawdzałem). Integracja z Rubym to pokłosie opensource'owego projektu, który został dołączony do systemu i jest wspierany przez inżynierów Apple'a. A obecność w systemie oznacza, że aplikacja stworzona pod Leoparda będzie działała tak samo dobrze na komputerze geeka jak i grafika komputerowego, który na oczy nie widział terminala.
Najciekawszy kąsek zostawiłem jednak na koniec...
Połączenie Ruby i Objective C nie jest prostą sprawą, dostarczany z Leopardem binding RubyCocoa wymusza kod, który wygląda bardzo nienaturalnie dla Rubiego, właściwie jak przepisanie specyficznych konstrukcji z ObjC na Rubiego. Zupełnie inne podejście, moim zdaniem rokujące o wiele, wiele lepiej mają autorzy projektu MacRuby. W ogólnym zarysie jest to przeniesienie Ruby 1.9 do środowiska uruchomieniowego Objective C. Czyli zamiast mapowania i spinania ze sobą typów Rubiego i ObjC/Cocoa MacRuby od razu posługuje się typami z Objective C dodając lukier składniowy Rubiego. A jaki jest efekt tej mieszanki? Otrzymujemy gorące kakao:
-
require 'hotcocoa'
-
class Application
-
include HotCocoa
-
-
def start
-
application :name => "Helloworld" do |app|
-
app.delegate = self
-
window :frame => [100, 100, 200, 100], :title => "Helloworld" do |win|
-
lab = label(:text => "Hello from HotCocoa", :layout => {:start => false})
-
win <<lab
-
b = button :title => 'Hello'
-
b.on_action { lab.text='Action!' }
-
win<<b
-
win.will_close { exit }
-
end
-
end
-
end
-
end
-
-
Application.new.start
Jeszcze więcej informacji o MacRuby znajdziecie tu i tu. Szczególnie atrakcyjnie wygląd plan produkcyjny - jeszcze w tym roku ma być wypuszczona pierwsza stabilna wersja. Mam wrażenie, że koncepcyjna kompatybilność Rubiego i Objective C może się przerodzić w całkiem nową jakość, która docenią świeżaki zaczynające developerkę pod Mac OS X.
[objective c os x ruby]









Tomek Wójcik said,
September 23, 2008 @ 10:25
No właśnie ja jakoś nie mogłem przekonać się PyObjC. Próbowałem, napisałem nawet dwie mini-aplikacje, ale po prostu nie dałem rady. Być może problem leżał w ogólnej nieznajomości Cocoa i ObjectiveC, co skończyło się brakiem umiejętności rozumienia dokumentacji…
Tak czy siak od dłuższego już czasu poznaję i ObjectiveC i Cocoa. Pomimo mojego umiłowania Python’a nie wyobrażam sobie dzisiaj tworzenia aplikacji dla OS X w innym języku. Rewrite’y narzędzi napisanych w Python’ie i AppleScript powstają jak grzyby po deszczu, co utwierdza mnie w przekonaniu, że Cocoa to “moje” środowisko :).
Do Rubiego zraziłem się próbując podejść do RoR, które mnie odrzuciły na kilometr :). W dodatku niejednolita składnia i brak konkretnego podręcznika (który nie potraktuje mnie jak idioty i nie będzie mnie uczył podstaw OOP) pogłębiły to moje wewnętrzne “fuj” :).
Pozdrawiam.
daniel said,
September 23, 2008 @ 10:36
@Tomek - myślę, że nie sposób programować pod osx bez wgryzienia się w biblioteki - niezależnie od języka. Ruby ma swoje zakręty ale ja osobiście nie znalazłem nic bardziej wydajnego jeżeli chodzi o czas tworzenia softu. A fakt, że pełnię mocy można będzie zawsze wyciągnąć tylko za pomocą ObjC chyba nie podlega dyskusji.
Shoovi said,
September 23, 2008 @ 22:21
Dan: Czy instalowałeś już nowe iTunes, QT oraz UP systemu do versji 10.5.5? Jakaś przestroga (np. przed iTunes? :)
Do Twojego posta dorzucę 2 swoje grosiki ;) jako, że jaPko mam mniej więcej tyle co Ty. Skład video na iWorks jest bajecznie prosty, generowanie sympatycznych slideshow’ków w iPhoto jest szybkie i efektowne.
Co mnie wkurza w sprzęcie:
- mysz, której po prostu nie czuję i za nic nie mogę jej wystarczająco dobrze ustawić. Mam takie zboczenie jeszcze z Amigi na której sporo rysowałem, że muszę czuć mysz, wszelkie milisekundowe lagi sa niedopuszczalne ;)
Co więcej łechtunia mighty mouse jest nad wyraz wrażliwa na wszelkie zabrudzenia, najlepiej używać jej w rekawiczkach
Co jest ok w sprzęcie:
- iMac jest cichutki
- nie kurzy się - mojego peceta musiałem często wycierać z kurzu, nie mówiąc już o ekranie, natomiast materiały Apple’a wyraźnie mniej się elektryzują! Dla mnie bardzo ważna rzecz
Aha, czasami na tym blogu Tu można dorwać ciekawy darmowy soft na Maca.
Jako php’owiec nadal szukam swojego środowiska, może ktoś cos poleca? :)
pozdro
Shoovi said,
September 23, 2008 @ 22:24
Sorki za pomyłkę w linku adres docelowy powinien być taki http://www.hongkiat.com
daniel said,
September 23, 2008 @ 22:48
@shoovi ja używam mbp całkowicie z zewnętrznymi gratami (i zamkniętą klapą) i o ile klawiry mam apple’a o tyle korzystam z myszki logitecha (jestem z niej bardzo zadowolony - spróbuj może Ci podejdzie MX 518 bodaj się zowie)
Update systemu poszedł i nic złego nie zarejestrowałem, ciekawe bundle z softem po bardzo dobrych cenach są też na http://macupdate.com - tak kupiłem m.in świetny soft contactizer pro
Shoovi said,
September 23, 2008 @ 23:58
Dan: Poczytałem o tym, ciekawe. So far wystarcza mi rainlendar w pracy na pulpicie, może jak będe miał swoją firmę to zainwestuję w coś tak zacnego ;)
Wracając do systemu to sprawia mi pewien klłopot dostosowanie się do niektórych aplikacji z “aj” na poczatku. Chodzi o wymuszanie przechowywania bibliotek, baz itd. nie w tych miejscach gdzie ja chcę tylko w systemowych. Np. iTunes, niby spoko, ale przebudował mi całą bazę utworów ;) i takie tam drobnostki, pewnie to zwykły brak doświadczenia, no ale… ;)