Can I run swift compiler in Linux?

Yup! Apple only distributes builds for 64-bit Ubuntu, on other distros you’d have to compile it on your own.

Short installation instructions:

1. sudo apt-get install clang libicu-dev

2. Download binaries from here:

3. Extract them (tar xzf swift-…tar.gz)

4. Add <extracted directory>/usr/bin to path environment:
export PATH=/path/to/usr/bin:"${PATH}”
preferably append this to your shell configuration file 
(.zshrc in my case)

5. Try running ‘swift’ command to verify your installation

Full installation instructions provided by Apple (ignore key validation steps, they’re not required):

If you’re running a Linux Virtual Machine from Mac, I strongly recommend using Parallels Desktop over free alternatives (has 14-day trial). After installing Parallels additions I got 2D and 3D hardware acceleration and smooth user experience, which I never got on VirtualBox.

How do I use it?

swiftc is a compiler (run swiftc —help), but in the beginning you’ll find swift REPL much more useful (just run: swift). It allows you to run swift code using interactive mode (scripting language style). Works fairly well, I do recommend it.

Can I run all this on Windows?

Not right now, currently it only builds on Linux. You can install Ubuntu 64-bit virtual machine and go from there.

What IDE should I use?

That’s a tough one! The only IDE that supports Swift (and doesn’t suck) is CLion from JetBrains. Yes, it’s proprietary (you get a free trial), but it’s pretty much your only choice (if you don’t feel like going back to 80-ties and coding in your text editor).

Currently stable release doesn’t support Swift plugin, you need to install (potentially unstable) Early Access Program version from here:

There’s also a Swift plugin download link on the page above, grab that one too. Then follow official configuration instructions:

Don’t make a mistake of skimming through them, they’re crucial. Pay attention to the CMakeLists file, you’ll have to configure yours too (add_swift live template helps in getting that chore done).

On the bottom of the article there’s a YouTube video presenting how properly configured IDE should behave and look like:

That’s as good as it gets with Swift on non-Apple OS.

In my case I experienced some EAP build crashes and the whole IDE worked much, much slower than it’s Mac OS version. At this point I gave up and just run the same version of CLion on my OS X natively.

If you have trouble configuring your CMake file in CLion, type add_swift in there, it’ll expand to a full template. After you do that, you should be able to create, compile and debug some Swift files. Enjoy!

Can I build iPhone apps on Linux? Pretty please?

Nope, you can’t. Swift is open source, as is it’s standard library, but Cocoa framework is not. You’ll never be able to write apps for iOS on Linux/Windows using Apple’s technologies. Deal with it. And you wouldn’t really want to: on Mac even if you’re normally using AppCode, you still revert to XCode from time to time. Like it or not, as an iOS developer you always depend on XCode to some extent.

Soo… is Swift programming on Linux a viable choice?

I would say it is, but only for learning purposes, not for writing anything useful. If you want to just play with the language, see for yourself what the hype is all about and how coding in Swift feels like, by all means, dive in swift REPL. It’s a tremendous help in learning the language and it runs perfectly fine on linux.

However if you want to write a more serious project in swift (not just play with some code samples from a book) just get a Mac. Your life it’s going to be so much easier, I promise. The tools that we have on OS X (Xcode, Code Runner, AppCode) are miles better and everything just works seamlessly. Plus you actually can write iOS apps, which will never be the case on Linux.


Daqri is a company trying to change the way people work in industrial environments by introducing augumented reality into the workplace. They’re most notable for an AR smart helmet they’ve designed and produced ( This weekend they concentrated on coordinating an event in DCU Innovation Center in Ireland.

While most participants were from Dublin, some people came from Spain, USA, Poland (me!) and even New Zealand. Apart from networking and getting to know each other, the goal was to develop an augmented reality app.

We were encouraged to use technologies like 4D Studio (web based tool created by Daqri), ARToolkit (open source AR library), Melon (dry-electrode EEG reading headband) or even Daqri Smart Helmet SDK.

I paired up with an italian developer Vincenzo F. to work on his idea of an augmented reality book reader. After a day and a half of struggling with Android SDK, OpenGL and ARToolkit, we managed to code a prototype showing the potential of this technology. You can take a look at a short video here:

Overall attending the hackathon was a very pleasant experience – I had tons of fun, met lots of passionate people, learned a lot about augmented reality and current state of technology.

Daqri is planning to organise another hackathon next year, so you can still experience all the above for yourself. Be sure to follow their twitter profile (@DAQRI) to keep up with what they are up to!

Mobile Central Europe 2014

Games are fun, no doubt about it. Turns out not only playing them, but also making can be a source of tons of enjoyment and satisfaction. This is how I got into programming in the first place – I just wanted to learn how to create my own RPG.

So I paid the conference fee (turns out it’s not always beneficial to be an ‚early adopter’, promocodes were easy to obtian later on), paid for the flight ticket to Warsaw, Poland (my home city btw) and joined other fellow programmers listening to the first lecture delivered by Mike Lee (@bmf on Twitter).

And what do I hear? His main point was: Don’t make games, it’s a VERY expensive hobby. Oh, and also: don’t make games. Did I mentioned don’t make games already?

Yeah, right – perfect start of the day – hearing Mike contradicting the whole reason I got into writing software in the first place ;)

Actually it was hardly a shocker for me, but some of his points were very eye-opening. Times when I shared this worldview that professional game development is a dream job are long gone. There’s a reason I’m making a more traditional ‚business’ software.

Anyways, the conference was great. I didn’t expect the first edition of any IT conference to be so well organised and overall so valuable. Great speakers lineup, fenomenal venue (in a cinema!! yay!), lots of really nice peope. To be honest as one of the first people to buy a ticket I didn’t expect much (the website was almost empty when I signed up). But over time (with more and more speakers anounced) it became obvious that the event is going to be huge and very worthwhile.

Unlike most Polish conferences, this one attracted mostly international (and mostly well-known) speakers, which is rather unusual and especially noteworthy considering the event price. To name just a few, we had a chance to listen to Chris Eidhof, Ortha Therox, Jon Reid and Peter Steinberger. Three simoultaneous lecture tracks guaranteed that one wouldn’t end up listening to something he didn’t find interesting.

One talk that got me thinking was Drew Crawford’s ‚UI testing sucks’. This is something I’ve been looking into recently (Calabash in particular). He made an argument that the UI automation tools need to have so many assumptions (which will not always hold true), that where possible we should focus on writing correct unit tests first and only then start thinking about automated UI testing. Or even think about dropping automated UI testing completely in favour of TDD. I’ve got too little direct experience with BDD to comment on that, but that’s a certainly interesting point.

Did I mentioned how cool the venue was? Not only did we have enormous cinema screen sizes and very comfortable chairs, but also we didn’t have to go to a pub for the afterparty. For me that’s a huge benefit – as a non-native english speaker I find it difficult to talk with others in environments having lots of loud background noise.

Oh and during the afterparty the attendees were able to play some games.. on a cinema screen. Pretty cool, huh? ;)

Unfortunately I didn’t get a chance to join a preceeding event – JITTER hackaton that happened on friday. You can check out the official hackaton video here (includes some footage of the actual conference).

In short: the conference turned out waay better than I anticipated. It could easily compete with similar events that happen abroad, only it beats them with the ticket price ;)

Will I go next year? Sure I will! And you should too, it’s worth it!

If you read my blog from time to time you probably noticed a trend that I attend a technical conference, get excited about it and afterwards describe how awesome it was, encouraging you to join next year. Well, this post will be no different ;)

While usually (at least in Poland) mobile conferences tend to cover whole bunch of platforms (or at least the two most popular ones), iOSDevUK was centered purely around iOS development. Which makes it especially interesting, since it creates a great opportunity to meet lots of people who deal with the same stuff you do professionally and exchange experiences.

The venue



It took place in a picturesque small west coast welsh town of Aberystwyth (prepare for a daily seagull-induced wakeup). Apart from fantastic landscape, the location provided local pubs around every second corner, which inevitably led to socializing over a pint every evening :)

Both the lecture rooms and the default accommodation were on the university campus, which resulted in a really affordable conference fee. Some voices on twitter complained about a claustrophobic dorm rooms (or unfriendly electronic shower user interface), but I don’t think you need any more luxuries for a 3-day stay (wifi worked in the dorm rooms, what else could we possibly need? ;)

Protip: if you travel overseas (like I did), it helps to actually read the travel hints on a conference website. That would have saved me a few hours journey (Birmingham International is the preferred airport of choice, not any of the London ones).

The lectures

As usual, quality of the lectures varied. Some that I expected to be excellent, turned out to be so-so, other ones which I didn’t even want to attend, turned out to be really enjoyable.

Overall – I didn’t experience any epiphany listening to the talks, but I never felt like attending to any of them was a poor use of time.

The only thing I didn’t like about the lectures was that they haven’t been video-recorded. Which means if you were interested in two sessions happening simultaneously, there was no way to benefit from both (we had two tracks of talks most of the time).


Playing with Arduino bluetooth board and pulsating hedgehog app with @miguelquinon

Not all the lectures were full-length. The conference incorporated the idea I’ve heard about, but have never seen ‚implemented’: 5-minutes lightning talks. That turned out very well, I’d love to see more conferences allowing this short speech format.

Apart from the lectures, there have also been a bunch of workshops (including Core Data one conducted by Marcus Zarra) and an Arduino hack (which became way more fun after pizza, beer, nerf gun and hedgehog images came into play).

The people

The attendees are usually the highlight of all conferences, this time it was no different. Momentarily it was just a tiny bit surreal for me to see and/or chat with the iOS tutors known from the internet that I didn’t ever expect to meet in person. And judging by the other people’s reactions and standing ovations after Dave Verwer’s talk (the guy behind iOS Dev Weekly), I presume that at least some other people shared that feeling.

For me as an introvert and non-native English speaker (far from the best one) it was definitely a stretch to have so many conversations with people over such a short period of time, but I absolutely enjoyed it.


Overall I really enjoyed the conference and had a blast! It’s always a little bit inconvenient to attend an event happening in the middle of the week, but this time it was absolutely worth it, no doubt about it.

Big thanks to Chris Price and all the other organizers for their huge effort put into organizing the event and see you all next year!

Btw. if you missed the opportunity to join iOSDevUK this year, there’s another iOS conference happening shortly (17-19 of September), check out NSSpain website!

Kilka tygodni temu pisalem o idei 7-mio dniowych prob. Wspomnialem rowniez, ze chce od razu wdrozyc pomysl w zycie. Planowalem przez 7 kolejnych dni pisac i umieszczac nowe notki na blogu. Priorytetem bylo regularne publikowanie, nawet gdyby mialo odbic sie negatywnie na jakosci.

Niniejszy tekst jest krotkim podsumowaniem tego doswiadczenia.

Poczatkowo szlo mi niezle. Przez pierwsze kilka dni, udalo mi sie realizowac zalozenia. Terminowo opublikowalem dwie notki, trzecia (znacznie dluzsza), pojawila sie z jednodniowym opoznieniem. Jednak od tamtej pory, na blogu nie pojawil sie zaden post. Oznacza to, ze nie udalo mi sie zrealizowac zalozonego celu. Z planowanych siedmiu notek, ukazaly sie zaledwie trzy.

Oczywiscie – mozna szukac usprawiedliwienia. W dniach, kiedy nie udalo mi sie trzymac planu, bylem na tyle zajety, ze poswiecenie godziny czasu na blogowanie, bylo duzym problemem. Jednak pod koniec tygodnia, opanowalo mnie zwykle lenistwo. W ten sposob krotka – zaledwie 7-mio dniowa – proba, zakonczyla sie fiaskiem.

Ale czy na pewno?

Pewne porazki sa mimo wszystko lepsze niz inne. Czasem cos, co postrzegamy jako niepowodzenie, jest w rzeczywistosci krokiem naprzod. Tak wlasnie jest i w tym przypadku.

To prawda, ze nie osiagnalem zalozonego celu. Podjalem jednak pewne dzialania – udalo sie opublikowac trzy notki. Z jednej strony – nie jest to nawet polowa zalozonej liczby. Z drugiej – to az trzy notki w ciagu jednego miesiaca. Przez caly zeszly rok, opublikowalem zaledwie dwie! Tak wiec, pomimo „porazki”, w ciagu kilku dni, osiagnalem w sferze blogowania wiecej, niz przez caly poprzedni rok!

Pomimo, ze nie skupialem sie szczegolnie na jakosci tych kilku ostatnich notek, efekt koncowy okazal sie byc co najmniej zadowalajacy. Do tej pory pisalem raczej dla siebie – nie staralem sie wybierac tematow, ktore moglyby przyciagnac szersze grono czytelnikow. Tymczasem notka na temat pracy zdalnej, wzbudzila pewne zainteresowanie. Zyskala kilka retweetow, share’ow oraz wiadomosci na twitterze. Ponadto wczesniejszy wpis (na temat stalych statycznych w Objective-C), byl stricte techniczny. To dobra odmiana, od dawna nie umieszczalem tutaj tego typu informacji – porad dotyczacych jezykow i technik programowania, nie umieszczalem w ogole.

Tak wiec udalo sie osiagnac pozytywne efekty, pomimo ze poczatkowe zalozenia, nie zostaly spelnione. Dlatego wlasnie o efekcie koncowym mozna mowic zarowno w kategoriach porazki, jak i sukcesu.

W zyciu – niezaleznie od dziedziny – czesto jest bardzo podobnie. Nawet jesli nie uda nam sie osiagnac zalozonego celu, jesli osiagniemy „porazke”, czesto samo doswiadczenie uczy nas i wzbogaca.

Czas na kolejna 7-mio dniowa probe :)

Na zeszłorocznej Confiturze, prelegent Pawel Wrzesz zapytał słuchaczy, ile osób chciałoby pracować zdalnie, zamiast codziennie przychodzić do biura. Troche zaskoczyło mnie, jak wiele osób podniosło w odpowiedzi reke. W przeszłości pracowałem zarówno zdalnie, jak i na miejscu w firmie. I wiem, ze rzeczywistość moze nieco roznić sie od wyobrazeń.

Z pewnością praca w tym modelu nie jest dla wszystkich. Wiele osób przypuszcza, ze gdyby zostali w domu, nie byliby w stanie samemu zmotywować się do pracy przez 8 godzin dziennie.

Niektórym praca zdalna kojarzy się z kolei z obijaniem się i graniem na XBoxie, zamiast wysiłku i programowania.

Wielu ceniłoby sobie brak konieczności dojazdów do pracy – dla nich byłaby to znaczna oszczędność czasu.

Jeszcze inna grupa osób widzi korzyść w odcięciu się od wspołpracowników i możliwości pracy w środowisku ze znacznie mniejsza liczbą rzeczy, które nas rozpraszają.

W kazdej z tych opinii jest cześć prawdy, jednak żadna nie daje pełnego obrazu.

Moim zdaniem praca zdalna nie jest ani lepsza, ani gorsza od pracy z biura. Jest to po prostu alternatywa, inny model, z którym wiążą się nieco odmienne wyzwania i możliwosci.

Zalety pracy zdalnej

1. Brak sztywnych godzin pracy

To często bardzo duża zaleta – daje możliwość załatwienia czegoś w urzędzie albo wizyty u dentysty, bez konieczności korzystania z dnia urlopu. Z drugiej strony nie ma nic za darmo: „brakujące” godziny trzeba odpracować. Zazwyczaj można to jednak zrobić w porze, która będzie dla nas bardziej odpowiednia. Jeśli któregoś dnia wolimy wyspać się dłużej niż zwykle, ale za to wieczór spędzić na programowaniu, przeważnie nic nie stoi na przeszkodzie.

Nie zawsze jednak godziny pracy są tak swobodne. Często komunikacja w firmie odbywa się w dużej mierze w sposób synchroniczny i programista ma obowiązek stawić się (wirtualnie) o określonej godzinie na „daily standup” albo inne spotkanie. Wszystko zależy od pracodawcy oraz konkretnego projektu.

Dla mnie dużą zaletą nienormowanych godzin pracy jest możliwość drzemki w środku dnia :) Półgodzinny sen około 13-stej ma zbawienny wpływ na moją produktywność i motywacje do działania. Pozwala zrelaksować się i skutecznie zwalczyć poobiednią senność.

2. Możliwość pracy dla firmy z innego kraju (bez przeprowadzki)

Z punktu widzenia firmy, praca zdalna stwarza możliwości współpracy ze specjalistami, którzy nie są dostępni na lokalnym rynku. Wiążą się z tym dodatkowe komplikacje (różnice w strefach czasowych!!!), ale moim zdaniem korzyści przeważają niedogodności.

Ponadto pracownik z innego kraju jest często znacznie tańszy – firma płaci za niego mniej, niż za lokalnego programistę o porównywalnych kwalifikacjach i umiejętnościach, a jednocześnie osoba zarabia więcej, niż dostałaby w swoim miejscu zamieszkania. Często o rząd wielkości więcej. Win-win.

3. Lepsze warunki pracy – sprzęt

Ten punkt zależy od warunków, jakie mamy w domu. W moim przypadku – w pokoju mam bardzo dobre wyposażenie. Miedzy innymi duży, zewnętrzny monitor, bardzo dobre krzesło biurowe, zewnętrzne głośniki, klawiaturę mechaniczną, dużą przestrzeń pracy, itd.

Wydaje się, że nie są to jakieś wspaniale warunki, jednak do tej pory nie miałem takich w żadnej z firm, z którymi współpracowałem. Dwa monitory nie wszędzie są norma, o klawiaturze mechanicznej często nie ma co marzyć. A krzesło? Dla mnie to największy problem.

Najtańsze krzesła biurowe, które nie są cichym zabójcą kręgosłupa, kosztują po 650 zł (Grospol Futura 3). Bardziej zaawansowane modele potrafią kosztować do kilku tysięcy (bardzo popularne są modele w przedziale cenowym 1300 – 1700 zł).

Z punktu widzenia firmy, takie wyposażenie dla każdego pracownika, to zbędny, zbyt duży wydatek. W efekcie często dostajemy krzesła biurowe za 200 zł, które nadają się tylko na śmietnik.

Cześć osób z pewnością nie zgodzi się z tym stwierdzeniem, uzna ze ich rozpadające się krzesło jest wystarczająco dobre. Ciekawe tylko, co ich kręgosłup odpowie na to za kilka lat. Ja spędzam na fotelu biurowym około 10-12 godzin dziennie. Dla mnie to niesamowicie istotna sprawa.

Niektóre firmy maja również problemy z jakością sprzętu elektronicznego – zapewniają pracownikowi maszynę, która nadaje się jedynie do przeglądania internetu. Zbyt dużo czasu zmarnowałem (prywatnie) na tego typu sprzęcie. To jest pozorna oszczędność – pieniądze przeznaczone na rozsądnej jakości komputer, zwrócą się szybko poprzez zwiększoną produktywność. IDE crashujace się co pól godziny z powodu braku pamięci (i podobne problemy) tylko odciągają nas od pracy i wybijają z rytmu. Strata czasu i nerwów.

W domu przeważnie mamy jednak dobry sprzęt. Jako programiści, dbamy o to, żeby nasze maszyny były w miarę nowe. Nie jest tu konieczna przesada – laptop za 10 tysięcy to prawdopodobnie zbędny wydatek (ale i tak rozsądniejszy niż sprzęt za 1500 zł, którego zakupu będziemy żałować każdego kolejnego dnia). Nie ma powodu popadać w skrajności, w miarę nowy komputer ze średniej półki powinien wystarczyć do większości zastosowań (koniecznie z dyskiem SSD!!).

Z drugiej strony laptop często nie jest jedynym narzędziem pracy. Możemy dodatkowo potrzebować dostępu do urządzeń, które znajdują się w biurze. W moim przypadku (mobile developer) takie sytuacje zdarzają się jednak niezwykle rzadko.

4. Lepsze warunki pracy – mniej rozproszeń (= większa produktywność)

Z tym bywa roznie. Jesli ktos ma w domu male dziecko, to z pewnoscia bedzie mu trudno skupic sie na pracy. Jednak najczesciej pozostali domownicy spedzaja wiekszosc dnia w pracy/szkole i mieszkanie jest puste. Pozwala bez przeszkod skupic sie na pracy.

Tymczasem w biurze czesto przeszkadzaja nam rozmowy innych pracownikow, szum i halas, spowodowany siedzeniem w open space. Po prostu trudniej sie skupic, jesli siedzimy w pokoju razem z 10-cioma innymi osobami, z ktorych trzy sa akurat na callu, dwie inne pair-programuja, a kolejne trzy po prostu ze soba rozmawiaja. W domu przewaznie tego typu rozpraszacze nie wystepuja (sa za to inne).

Wady pracy zdalnej

1. Utrudniona komunikacja

Przebywajac fizycznie w jednym pomieszczeniu z innymi osobami z tego samego projektu, komunikacja jest latwa. Wiemy, kogo o co zapytac, znamy wspolpracownikow osobiscie. Wiemy, jak wygladaja i jak sie zachowuja. Podczas rozmowy z nimi, odbieramy zarowno bodzce werbalne, jak i niewerbalne. Rozpoczecie rozmowy jest szybkie i proste.

W przypadku pracy zdalnej, tracimy te atuty. Rozmowa z inna osoba odbywa sie przez telefon/sluchawki. Nie widzimy drugiej osoby. Trudno nam sie z nia porozumiec. Nie mozemy omowic pewnych spraw i problemow przy tablicy, z markerem w reku. W dodatku czesto slabo znamy osobe, z ktora chcemy sie porozumiec (albo nie znamy jej w ogole). Nie wiemy, co mysli i czego od niej oczekiwac.

Wydaje sie, ze komunikacja nie powinna byc duzym problemem. Mamy do dyspozycji nowoczesna technologie, maile, telefony, voip, videokonferencje. A jendak wciaz z osobami, siedzacymi w tym samym pomieszczeniu, pracuje sie po prostu latwiej. Bariera rozpoczecia rozmowy z kims, kto siedzi obok, jest po prostu znacznie mniejsza, a sama rozmowa przebiega znacznie efektywniej.

W moim przypadku problemy komunikacji wiaza sie rowniez z utrudnionym przekazywaniem feedbacku od pracodawcy. Zdarza sie, ze nie jestem pewien, czy wywiazuje sie z oczekiwan przelozonego i czy wykonuje moje zadania w sposob zgodny z jego wizja. Niezaleznie od modelu pracy, staram sie o to dopytywac, jednak w przypadku wspolpracy w tym samym budynku, jest to po prostu latwiejsze.

2. Utrudniona współpraca

Problemy utrudnionej komunikacji staja sie wyraznie widoczne, kiedy probujemy przekazac nasza wiedze innym osobom. Kiedy probujemy pomoc im w wykonywaniu danego zadania. Jesli druga osoba siedzi obok, poza ekranem jej komputera, widzimy rowniez jej reakcje na to, co mowimy. Widzimy, czy wspolpracownik nadaza za naszym tokiem rozumiowania, czy nie ma bladego pojecia o tym, co mowimy.

Kiedy trzeba cos zaprojektowac, mozna podejsc do tablicy, albo wziac kartke papieru i efektywnie rozpatrywac nowe pomysly. W przypadku wspolpracy zdalnej, jest to zdecydowanie utrudnione. Nieprzypadkowo artefakty fazy projektowania oprogramowania rzadko sa outsource’owane, najczesciej w modelu pracy zdalnej odbywa sie faza konstrukcji, w ktorej wymagania (teoretycznie) sa juz wczesniej ustalone.

3. Samotność

Ten problem nie pojawia sie na poczatku, wystepuje dopiero po pewnym czasie. Mozna og odwlec w czasie, poprzez prowadzenie bujnego zycia towarzyskiego poza praca, jednak nie mozna calkowicie sie od niego uwolnic. Po prostu, jesli bedziemy siedzieli codziennie po 8 lub wiecej godzin, pracujac w samotnosci zdalnie, szybko zacznie nam brakowac ludzkiego towarzystwa. Co ciekawe, dotyczy to rowniez introwertykow, ktorzy maja naturalne problemy z nawiazywaniem i pielegnowaniem znajomosci. Po prostu czlowiek jest istota spoleczna i dluzsze przebywanie w samotnosci wplywa negatywnie na samopoczucie. Praca z innymi osobami w tym samym pomieszczeniu jest po prostu ciekawsza.

4. Konieczność zadbania o motywację do pracy

Nie kazdy jest w stanie wstac rano i od razu zabrac sie do pracy. Maile, Facebook i inne rozpraszacze, potrafia pochlonac wieksza czesc dnia. I czlowiek moze zorientowac sie, ze jest godzina 15, a on tak na prawde jeszcze nie zaczal pracowac.

W poczatkach mojej pracy zdalnej, mialem z tym problemy. Trudno bylo mi pracowac przez 8 godzin dziennie, poniewaz po prostu zbyt pozno zaczynalem. Poczatek dnia wypelniony byl prokrastynacja. Jednak zwalczylem ten nawyk – w tej chwili pracujac z domu, od razu po wstaniu z lozka, zabieram sie do pracy (jeszcze przed sniadaniem). W efekcie zdarza sie, ze jeszcze zanim inni dotra do pracy, mam kilka dobrych commitow, wypchnietych do repozytorium. Jest rowniez dodatkowa zaleta takiego podjescia. Z samego rana, inne osoby nie dotarly jeszcze do biura – mozemy wiec pracowac bez obaw, ze przerwie nam telefon od innego wspolpracownika. Po prostu latwiej sie wtedy skupic. W ten sposob, jesli wstane troche wczesniej, przez pierwsze 2 godziny jestem w stanie zrobic wiecej, niz przez kolejne 4, kiedy juz inni wspolpracownicy dotra do biura (pod warunkiem, ze mam jasno okreslone cele, ktore jestem w stanie zrealizowac bez pomocy innych).

Co ciekawe, najlepzsym remedium problem niedostatecznej motywacji do dzialania, zdaje sie byc wlasnie ustalenie stalych godzin pracy. Pozwala to szybko popasc w rutyne, czas potrzebny na ‚rozgrzewke’ i rozpoczecie pracy, zmniejsza sie z kazdym dniem. Mi dodatkowo pomaga fakt, ze w tej chwili mam osobny komputer do pracy oraz osobny prywatny. W laptopie od pracodawcy, nie ma skonfigurowanych zadnych prywatnych kont pocztowych, klienta twittera, itd. Jednak nawet w przypadku pracy z komputera prywatnego, mozna zasymulowac rozlaczne srodowiska, poprzez zalozenie odrebnego konta uzytkownika do zastosowan prywatnych oraz komercyjnych. W ten sposob w trakcie pracy nie bedzie kusic nas sprawdzanie prywatnych wiadomosci.

5. Trudności w trackowaniu czasu oraz rozgraniczeniu czasu pracy od czasu wolnego

Pracujac z domu, musimy pamietac o trackowaniu czasu. Jesli wyjdziemy w srodku dnia na poczte albo do lekarza, ten czas nie wliczas sie do czasu pracy. Na szczescie rozwiazania technologiczne, znakomicie nam w tym pomagaja.

Problem pojawia sie jednak, jesli zaczynamy research na jakis temat. Co jesli zaczniemy przeszukiwac informacje na blogach, czytac artykuly, na ktore nie poswiecilibysmy czasu, gdybysmy siedzieli w pracy? Poczatkowo mialem z tym problem, w tej chwili po prostu w godzinach pracy nie spedzam czasu na przegladanie witryn internetowych, ktorym nie poswiecalbym uwagi, bedac w pracy.

Niemniej jednak pracujac zdalnie, zdarzy sie, ze w srodku dnia pracy, zrobimy sobie dluga przerwe – na spacer, wyprowadzenie psa, czy cokolwiek innego. Jesli przerwa rozciagnie sie w czasie, brakujace godziny trzeba nadrobic. W ten sposob bardzo latwo wydluzyc sobie prace z godziny 9-17 na przyklad do 9-20 z przerwami. Z jednej strony zazwyczaj powoduje to, ze jestesmy bardziej produktywni i wypoczeci, z drugiej – wlasciwie spedzamy caly dzien w pracy, dopiero po 20 jestesmy naprawde wolni.

W przypadku pracy z biura, zazwyczaj po prostu opuscilibysmy budynek po 8 godzinach i nie spedzali czasu na dodatkowe aktywnosci. Po 17 mielibysmy wolne.


Praca zdalna nie jest pozbawiona wad i zalet. Nie mozna jednoznacznie stwierdzic, czy jest lepsza i wygodniejsza, czy gorsza, niz praca w siedzibie firmy. Po prostu wymaga innego podejscia. Nie kazdy projekt moze byc realizowany w modelu pracy zdalnej. Najwazniejszym problemem, ktory stwarza praca na odleglosc, jest utrudniona komunikacja z innymi. Najwiesza zaleta – zdecydowanie zmniejszona liczba rzeczy, ktore moga nas rozpraszac w trakcie pracy. A co za tym idzie – zwiekszona produktywnosc.

Praca wylacznie zdalna, na dluzsza mete wydaje sie byc dosc trudna, Samotnosc, problemy komunikacyjne oraz problemy z motywacja do pracy, predzej czy pozniej dopadna osoby pracujace z domu.

Rozwiazaniem wydaje sie byc praca z domu jedynie okazjonalnie – do kilku dni w tygodniu (1-2 dni w tygodniu to rozsadna liczba). Alternatywnie warto rozwazyc model, w ktorym kazdego dnia pracujemy poczatkowo z domu, a dopiero potem przenosimy sie do pracy. Aktualnie pracuje w ten wlasnie sposob i jest to chyba najlepsze polaczenie.

Zauwazylem, ze czesc moich znajomych programistow nie jest przekonana, co do sposobu prawidlowego definiowania stanych w Objective-C. Wiekszosc osob uznaje wyzszosc uzycia stalych w stosunku do makra #define. Jednak sam sposob deklaracji stalej budzi watpliwosci.

W przypadku stalych, ktore maja byc widoczne w wielu plikach .m, sytuacja jest prosta – deklarujemy stale w pliku .h, wykorzystujac slowo kluczowe ‚extern’. W pliku implementacji .m przypisujemy im wartosc:

// Const.h
extern const int constantAccessibleFromMultipleFiles;

// Const.m
const int constantAccessibleFromMultipleFiles = 55;

W przypadku definiowania literalu, kod bedzie wygladal podobnie:

// LiteralConst.h
extern NSString *const literalConstant;

// LiteralConst.m
NSString *const literalConstant = @"I haz code";

NSString *const oznacza staly wskaznik na napis, NSString const* byloby z kolei wskaznikiem na stala (mozna przypisac do niego inna stala w trakcie wykonania programu).

Jakie zastosowac podejscie, kiedy chcemy, aby stala widoczna byla tylko w jednym pliku? Deklarujemy ja na poczatku pliku impementacji *m. Ale w jaki sposob?

Mamy dwie mozliwosci:

// ImplementationFileConstOne.m
NSString *const implementationFileConstOne = @"one";


// ImplementationFileConstTwo.m
static NSString *const implementationFileConstTwo = @"two";

Prawidlowa jest opcja druga. Czesc osob nie jest jednak przekonana i czesto pomija slowo kluczowe ‚static’ przy deklaracjach stalych w plikach .m. Czy ten blad ma jakies uzasadnienie?

Otoz ma. W jezyku C++ nie ma roznicy pomiedzy stala deklarowana przy uzyciu slowa kluczowego ‚static’ oraz bez niego. Bardziej precyzyjnie: w C++ stale globalne sa domyslnie statyczne. Oznacza to, ze linkowanie jest ograniczone do jednej jednostki translacji (jednego pliku cpp, ‚internal linkage’).

// OffsetConsts.cpp
const int offset = 20;

// OffsetConstsEquivalent.cpp
static const int offset = 20;

Oznacza to rowniez, ze w C++ nawet bez uzycia slowa kluczowego ‚static’, mozliwe jest deklarowanie stalych o identycznych nazwach (w roznych plikach .cpp). Nawet jesli przypiszemy do nich inne wartosci, nie spowoduje to bledu linkowania.

// ConstantsFileOne.cpp
const int offset = 10;

// ConstantsFileTwo.cpp
const int offset = 30;

W jezyku C jednak zachowanie jest inne. Stale globalne nie sa domyslnie statyczne. Proba zdefiniowania niestatycznych stalych w wielu plikach .c, spowoduje blad linkowania. Rozwiazaniem jest definiowanie stalych jako statyczne w plikach .c:

// ConstantsInCFileOne.c
static const int offset = 10

// ConstantsInCFileTwo.c
static const int offset = 30;

Powyzszy przyklad zostanie zlinkowany bez bledow.

Jak wyglada sytuacja w Objective-C? Jezyk ten jest rozszerzeniem C, maja zatem zastosowanie takie same zasady. Stala zdefiniowana bez uzycia slowa ‚static’ bedzie miala inny zakres linkowania, niz stala statyczna. Jesli w kilku roznych plikach zdefiniujemy stale o identycznej nazwie i zapomnimy dodac slowko kluczowe ‚static’, otrzymamy w rezultacie blad linkera.

Warto wiec zapamietac, ze stale definiowane w plikach implementacji w Objective-C nalezy poprzedzac keywordem ‚static’, natomiast w C++ nie jest to konieczne.