Disclaimer as this post is strictly related to Tricity Java User Group, and is relevant only to Polish readers, hence it will be in Polish :) Although I'm not giving up on blogging in English, yet ;)
Ostatnimi czasy na liście trójmiejskiego JUGa pojawiła się informacja o reaktywacji! :) Na całe szczęście.
Jeśli jesteś developerem z trójmiasta, niekoniecznie związanym z samą Javą, interesuje Cię dalszy rozwój, chcesz się czymś podzielić bądź posłuchać o przygodach innych to odezwij się, to nic nie kosztuje a sporo możesz zyskać.
Dla mnie idea JUGa jest wspaniała. Dzięki nim miałem okazję poznać ludzi i usłyszeć o technologiach, które normalnie były by poza kręgiem moich zainteresowań. Teraz zawsze projektując coś, mogę pomyśleć o dodatkowych technikach/technologiach i przypomnieć sobie kogo mogę poprosić o pomoc.
JUG to również świetne miejsce do prowadzenia dyskusji. Po każdej prezentacji (a niejednokrotnie w trakcie), zaczyna się panel. Tematy najróżniejsze, od technik programistycznych po różnice pomiędzy technologiami.
- Wytwarzanie oprogramowania to Twoja pasja (niekoniecznie w Javie)
- Pochodzisz z trójmiasta, bądź okolic (niektórzy JUGowicze dojeżdżali nawet z Elbląga).
- Chcesz spotkać innych pasjonatów
- Interesują Cię nowe trendy / technologie wytwarzania softu
to zapraszamy. Może po jakimś czasie się ośmielisz i będziesz chciał opowiedzieć o tym co robisz? Super przeżycie, super doświadczenie.
A i zaproście znajomych. Dajcie znać w swojej firmie. Ma być nas wielu. Chcemy szerzyć wiedzę o technologii i krzewić dobre praktyki. Im nas więcej tym owocniejsze spotkania.
Ps jak wrócę to kombinuję nad darmowymi warsztatami / eventami a'la code retreat, które pewnie dało by się zorganizować w ramach JUGa. Za trochę swojego wolnego czasu możesz się przy okazji dużo nauczyć, może to być więc powód by dołączyć do grupy.
Link do grupy: http://groups.google.com/group/jug-trojmiasto Warto też sprawdzać http://it.wtrojmiescie.org/
1. Lets play TDD (AKA rethink some patterns)
Some of you are probably already aware that I follow James Shore Let's play TDD series. After last episode I started to think about usual design and 'The Best Practices" that I use everyday at work. Why? Because if you're going to follow his videos from the beginning, you are going to see my comments every now and again, where I'm bitching about his design.
I especially didn't like his dollar class (value object used across whole application for calculations and rendering), up to the point that I've decided to branch his repository (everything is hosted on github), and fix it. Trigger for that was making Dollar class responsible for rendering itself onto swing components.
So after picking up a recording tool, setting project to work in Intellij and changing layout to more familiar, maven structure, I started to refactor. It took me 3 or 4 attempts to discover that James design had truth in it. I still did not like it, felt wrong (still does), and was totally different from all I was used to, but that was the first time that I thought about shutting up and just letting him do his job. On a first occasion I asked him to add persistence to his application, and watched how he solves that problem.
In last episode James started to struggle with what I waited for: how to be consistent with his current design, don't clutter VO with too many methods and don't expose internals of Dollar class at the same time. He ended the episode with question to us, watchers, on how we would approach this problem. I still think that moving parsing string out of VO to external factory class would be a good idea. There we could add two way conversion from Dollars to some universal format, most likely to String (as we want to write the value to text files and to text fields). Later, if needed, we could add formatting object to e.g. display negative values in different form.
But that's not what going to happen. I've seen in comments idea that he should persist only user inputs. After reading that I felt cheated, and that James is going to do something wrong, again. But after second thought I had to agree that it is a good option in this case, and fits well with how the rest of the application is designed. It's even extensible, in boundaries described by James in first episodes. So although I feel bit cheated, about James slipping from what I've assumed to be a corner, in the end I feel like a winner. I may observe that different approach, and I still may disagree with it and search for shortcomings of the solution. And finally, the biggest win for me: I started to rethink all the patterns that I'm using in a day to day work.
Thanks for that Mister Shore (and to the all commentators as well).
2. My quest for knowledge
As you probably know I've moved couple months ago to UK to work in ProQuest. If you haven't heard about it, then please check out my previous post.
While coming here I promised myself that I'll shut up and will try to listen more, especially that there are many, much more experienced people around. It's not easy as I disagree with many thins but I try to first see the bigger picture and ask why some things are done this way. Often it makes sens ;)
I should mention that any big change I let through peer review process. Thanks to feedback from other developers with much more experience in this code (and with programming at all), I'm able to observe how other people approach my problem and what they think about my ideas.
Working in PQ gave me a lot already. Enough to make this post go through long corporate approval if I would try to describe it, so I'll just skip to next point ;)
3. Open source and Pair programming
Following on mentioned experiences, recently I wanted to join some open source project. Warsaw JUG had a great timing on that, as Michał Margiel proposed to create software (link in Polish) for one of Polish conferences, Confitura (again, Polish link).
Sadly it took some time before he responded to volunteers and I already agreed to do Pair Programming with a good friend of mine, with hope that he'll be able to use that in his master thesis. So every Tuesday and Thursday we are obliged to show up and write some stuff. As a motivation tool, we agreed to pay small fees to wikimedia foundation or one of animal shelters, if we won't show up. But as it figures, they are unnecessary as we've been doing more informal/unscheduled sessions than the planned one :)
What I've learned from that?
My friend is coding a small financial application, that he's preparing for our other friend. He want to do it as fast as possible so he often cuts corners, IMO, in a bad way. However those session reminded me that sometimes simplest approach works well, and it is possible that it will be developed faster (initially), and actually may work better than well crafted solution.
Despite breaking many sacred rules (like encapsulation, using wishful file parsing, etc) what he created works. What's worse (for my ego) it works better than things that I proposed after first glance at code that was already there (e.g. parsing input files by regexp instead of relying on magic numbers).
Task done by application is fairly simple, parse input files, do some calculations and write the output of calculations into spreadsheet. Bread and butter of almost any application that we write, right? It's a standard application, with small exception tat it won't grow when is done.
And who am I to tell if that solution is worse then mine. They both works, and as there is no need for maintenance my approach is just over-engineered. I just feel like an idiot sitting in ivory tower, shouting why we should do this or that, when in fact those things won't ever be a problem. Same as with James Shore application. They both picked the right hammer for the job.
Don't get me wrong, I'm not going to advise you to start using public fields, violate DRY, single responsibility, or other basic rules. Those recent experience, helps me to take another step back and take a look on applications that I wrote/designed from bit other perspective.
In both cases (Lets play and PP coding) they are not over-thinking the solution. Features and solutions on how to implement are being introduced Just in Time.That is something I need to try out, although I don't know how yet. When I'm writing code it's like moving small parts, one at a time, from big drawing board inside my head, and placing them in the IDE. Breaking that will be hard, but I'll try at least once! :)
All of us want to change something in our application. That's natural, we are constantly learning. If you don't see way of improving your older code, then most probably your doing something wrong. When coding on daily basis in same environment with same people, it's easy to start improving our very specific style. But there are many people who want to and actually share their knowledge. Go out and check out, maybe someone will inspire you in very same way as James Shore inspired me to skip finishing drafts of other posts and write this one.
In 2012 I hope to change my style. I don't know how. In 2011 I was playing with different techniques, this year I want to learn at least one new language starting with coffescript/node.js (yes, js is a new language for me. Other than making things appear and disappear I don't do much with it ;)). I look forward to that and hope that it will affect my style at least a bit.
I also set myself resolution to write more often, so I hope that at least those 2 I can keep :) Till next time
as promised in previous post, this time I publish for first time in English (or something that I'm calling English). Please treat this as a response to all questions regarding where am I, what I'm doing and how I've got here. Also if you have any further questions please ask them in here, as most probably someone else will also ask me about it ;) Last thing, it may be boring, as I'm describing all sort of stuff ;)
Disclaimer As a full story is rather long, and more actors are involved then I'm willing to introduce, hence I'm allowing myself to make story simpler.
All began around June when company called Proquest was searching for contractors. They found my linkedin profile by Tapestry 5 keyword. I had little practical experience with T5 till now, however combined with my theoretical knowledge it was enough for them. We've made couple calls, exchanged some emails, I've taken online tests, they told me what they are doing and happy with answers we've decided to arrange interview in their UK office. In July I've been in Cambridge for face to face interview after which they started corpo process to join me with onsite team. Right after interview I was hyped by Howard Lewis Ship tweet, in which he thanked to proquest for help with dealing with a 'subtle bytecode generation bug'. Can I ask for better recommendation then from gather of Tapestry 5? :)
It took some time before everything was ready for my coming, but here I am. I have signed half year contract so I should be here till April (with exception of going to 33degree conference), what will happen next? Hard to say, and although we've started talking about it right now it's too early to say anything, I should know more soon.
Proquest - the client
Regarding company itself, I was excited to join they ranks, even if for just short time. Proquest is large corporation , scattered all around the world. Company main profile is searching and processing information.
They've come up with they own development process, which they follow for couple of years. Core team haven't changed much recently, and they got a lot of knowledge in the domain. Just one thing freaked me, and not just a bit but a lot. Open space. It's really open in here. I wanted to take a photo of that, but corpo rules... sorry :)
I thought that I've seen open spaces (in Zensar and in some degree in DC), but Proquest beats both those companies hard in that regard. Other than LCD screens nothing separates people from each other. And it wouldn't be so scary if the rooms were smaller, but they are large. It took me a while to get used to such office layout, and IMHO I was able to adopt so fast just because my desk is next to window, so it brings me some degree of comfort.
Top tip: watch out to not overdo with some concepts. Nonetheless I must admit that such layout has it advantages: communication is so much easier. On the other hand having a private chat is just impossible.
Technical - Tapestry :)
From technical point of view, it is journey of my dreams. Proquest adopted Tapestry 5 long before first stable version, when T5 was in early beta and since then, they are contributing to the project (mostly indirectly). They are also well aware what's going on with framework and cooperate with Howard Lewis Ship whenever they need to push some features badly (for example T5.3 reduces memory consumption on pages, by a ... lot, and guess who was using every beta version of that release :)) That approach works well for both sides, as T5 gets better, due to insights from large project, and Proquest gets features it needs faster.
Top tip 2: use Tapestry. Large corporation do, and it is happy with it ;)
From my point of view I can finally test my knowledge against real, live, large project, developed by people who really know the technology, and judge for myself what I like/dislike in T5. Other than T5 they don't use any other frameworks, just some basic libraries (test tools + apache commons and alike) and some 3rd party tools for search engine. After a month I can see that there is not much value that additional libraries/frameworks could add to the project. So I'm happy with pure java + t5.
Time to write something about the project itself. We are working on search tool that is used already by many academic and professional clients. Currently main clients are libraries and universities, however after some acquisitions, professional leg of users is growing fast. and it's likely that while using library system you had contact with one of Proquest tools already. Application is searching in large datasets of indexed databases (periodicals, books, articles, thesis, etc) and allows to work further with returned documents (e.g. set alerts, export results, etc).
I've been assigned to search team, so my tasks regard mainly everything between search boxes in the UI and 3rd party indexing tool available via set of services.
First of all it is good to just write code. Being developer takes a lot of burden out of one shoulder. But I'm starting to miss some things related to being in decision chain of the project so most probably before end of the contract, I'll spam couple of @ boxes with ideas regarding design, architecture and development process itself :)
Nonetheless it's refreshing and changes perspective helps to look at development from different angle, take step back and rethink some of your opinions. At least it helped me :)
Application is guarded by couple thousand of unit tests so it's harder to break anything. Sadly thousands of tests takes really long to run, I haven't broken the build yet, but I've seen couple of mails send by CI tool that should be titled 'Run all the tests before commiting, dumbass!'. I understand that it takes a lot of time, but I don't get how can you just skip that part?
Ok, that's more then enough for one time. Next time I'll publish some thoughts on T5 itself and after that let's head back to post promised earlier like null object pattern :P (ok on the way there maybe I'll write one more post about something about testing and tools)
So CU next time :)
PS oh BTW Top tip of all: if you are going to work abroad and are planning to finish some of your projects in free time, then it is good to remember to take your code with you ... Even more important when you left at home your vdisk with redmine and all tasks in it (c's you didn't know about http://www.hostedredmine.com :)
No więc właśnie się zarejestrowałem :)
W piątek w firmie powiedzieli, że mogę lecieć więc pewnie CU there :)
33 degree było najfajniejszą konferencją na której dotąd byłem i od dłuższego czasu czekałem na to by Grzegorz podał datę kolejnej edycji. Osobiście bardziej odpowiadałby mi kwiecień, ale trudno, nie można mieć wszystkiego :)
Polecam moje wpisy i zdjęcia z poprzedniej edycji. A w tym roku zapowiada się, że będzie równie ciekawie, jak nie lepiej :) Liczę, że spotkam tam sporo osób, których dość długo nie widziałem (przynajmniej pół roku ;))
Jeśli podoba Ci się co czasem tu skrobię, to będę wdzięczny jeśli podczas rejestracji podasz mój mail (michalgruca (shfit-2) gmail (kropka) com). Taka forma wirtualnego browara :)
Wiem, że wyjechałem bez zapowiedzi, wiem że miałem coś o tym napisać, ale głupi jestem. W korpie spytałem się czy mogę pstryknąć parę fotek bo o nich na blogu tworzę wpis właśnie.
Skończyło się tak, że dostałem zestaw zasad pisania o korporacji, zakaz robienia zdjęć i prośbę o draft do zatwierdzenia. Było zrobić jak z zensarem i po prostu publikować.
Jako, że każdy dzień przynosi trochę nowych informacji o miejscu pracy i technologii to wpis ciągle przerabiam i to w dwóch językach. Trochę tego za dużo więc powstaną raczej na pewno 2 wpisy i tylko po angielsku.
Zmiana języka raczej nie będzie na stałe, choć jeszcze to rozważam, ale wpisy pod zatwierdzenie w jedynym słusznym języku będą powstawać :)
Do poczytania więc i oby do zobaczenia w Krakowie :)
To teraz mogę już oficjalnie ogłosić.
Wyjeżdżam w przyszłym tygodniu na pół roku do UKejowa na kontrakt. Jak za pół roku będę dalej chciał promować Tapestry 5 to znaczy, że da i fajnie się z nim pracuje.
Opóźnienia w publikowaniu tekstów wynika w dużej mierze z tego, że teraz mam sporo innych zajęć okołopracowych. Zakładam, że jak już w Cambridge znajdę sobie lokum (jeszcze jestem bezdomny), to będę miał czas na pisanie. Tymczasem jeszcze o chwilę cierpliwości proszę i nie kasowanie mnie z favorites ;)
Mam nadzieję, że przez te pół roku zdążę doszlifować swój T5 warsztat na tyle by móc napisać o paru ciekawostkach jakie znalazłem podczas pracy :)