Mariusz Prowaźnik

o programowaniu w Javie, Scali i Clojure.


Jak wyzwolić kreatywność?

Do napisania tego postu zainspirował mnie artykuł "Arts coaching w służbie biznesu" z Business Coaching nr4/2010, który opisuje wykorzystanie pracy artystycznej w szkoleniach biznesowych. Nie będę oczywiście go streszczać, chciałbym się po prostu zastanowić na temat tego, jak można wyzwolić więcej kreatywności w pracy programisty.

Ta praca może dawać ogromne możliwości tworzenia, realizowania wizji nowoczesnego systemu, może też być tylko nudnym klepaniem kodu, łataniem dziur w podstarzałych aplikacjach. Programista może być ograniczony przez wiele zewnętrznych czynników, ale najważniejszym czynnikiem w tym procesie jest on sam, jego podejście i sposób myślenia, bo to człowiek jest źródłem kreatywności, dzięki której pokonuje lub obchodzi się ograniczenia i dzięki kreatywności praca staje się ciekawa i fascynująca.

Jak zatem tę kreatywność w sobie wyzwolić?

Nie piszę poradnika, chcę się tylko podzielić kilkoma spostrzeżeniami na ten temat, oraz myślami zaczerpniętymi z różnych innych źródeł. Dlatego jeśli z czymś się nie zgadzacie, macie inne spostrzeżenia, to zachęcam do komentowania.

Odpoczywając. Nie raz mi się przydarzyło zmarnować godziny na problem, który następnego dnia, po odpowiednim wypoczynku rozwiązałem w 5 minut. Zmęczenie i stres nie sprzyja pomysłowości. Nie bez powodu coraz częściej można się spotkać z tym, że programiści w pracy mają do dyspozycji "relax/chillout room". Dlatego warto zadbać, żeby pracę rozpoczynać wypoczęty.

Odmulając się. Na szkoleniach BHP zwykle mówią, by co godzinę robić pięciominutową przerwę, by podczas niej robić ćwiczenia rozciągające itp... Jak jest w praktyce? Programista siedzi i siedzi, klepie i klepie. Brak ruchu prowadzi do rutyny, rutyna prowadzi do automatyzmu, a automatyzm prowadzi do ... ciemnej strony mocy. Póki co programowanie nie jest jak praca przy taśmie, więc krytyczne i twórcze myślenie może się przydać. By je rozruszać, czasem wystarczy rozruszać siebie.

Pytając. Siebie i innych. Szukając inspiracji u innych, pytając jak radzą sobie ze swoimi zadaniami i próbując dla odmiany ich metody. Zastanawiając się, nad powodami stosowania takiego a nie innego stylu pracy, jakie są za i przeciw. Zidentyfikować przyjęte założenia i spytać siebie, czy na pewno są prawdziwe? Co można zrobić lepiej? Czy można zaryzykować, sprawdzić jakąś nową metodę, nowe narzędzia?

Robiąc burzę mózgów, tworząc mapy myśli. Zapewne większość z nas kiedyś uczestniczyła w burzy mózgów i ma jakieś wyobrażenie na ten temat. Nie wiem jak inni, ale ja dosyć długo nie zdawałem z istotnego elementu tego narzędzia. Zacytuję książkę Christine Ingham, Automotywacja na 101 sposobów:
Dyskusja i komentarze na temat względnych korzyści czy skuteczności każdego z nich odbywają się dopiero pod koniec sesji. Jej celem jest uzyskanie jak największej liczby pomysłów, bez względu na to, jak dziwaczne czy niepraktyczne mogą one się wydawać.

Istotne jest wyraźnie rozdzielenie fazy generowania pomysłów, od fazy oceniania ich. Przechodząc zbyt szybko do krytyki, można zablokować napływ wielu dobrych pomysłów, które często ewoluują z kiepskich. Z podobnym podejściem spotkałem się w programie Briana Tracy'ego o zarządzaniu czasem (link). Zalecał, by po określeniu problemu, wymyślić 20 rozwiązań. By pójść na ilość. Dopiero potem, wybrać jedno, najlepsze i je zastosować. W podobny sposób można użyć map myśli. Przed rozpoczęciem pracy, poświęcić chwilę na wyrysowanie swoich zadań, skojarzeń, wszystkiego co w głowie siedzi. Potem spojrzeć na to i wybrać jedną, najważniejszą, rzecz, której zrobienie będzie najlepszym wykorzystaniem posiadanego czasu.

Tworzyć sztukę. Artysta, w odróżnieniu od rzemieślnika, tworzy coś co stanowi wartość estetyczną, nie użytkową. Nie chodzi o cel, o to czy powstanie jakiś produkt, ważne dla niego jest by zaangażować się w nieskrepowanym procesie twórczym, wyrażając siebie i swoje emocje. Oczywiście kod musi być użyteczny, programowanie nie jest dziedziną sztuki. Ale poświęcając się od czasu do czasu czemuś co jest dziedziną sztuki, może zaowocować pobudzeniem nieużywanych dotąd form myślenia i postrzegania.

Przy tym wszystkim warto zdawać sobie sprawę, że w kreatywności nie chodzi o recepty, jest ona przecież umiejętnością działania bez nich. Chodzi o inspirację i o to by być gotowym dostrzegać ją wokół. By pozwolić pomysłom rozkwitać, przeobrażać się i dać zaskakiwać się tym procesem.


Konfiguracja projektu z profilami Mavena i Springiem

W poście tym pokażę, jak przy użyciu Spring'a i profili Maven'a można uporządkować sobie konfigurację projektu, która jest zależna od środowiska na które jest wdrażany projekt. Oto przykładowe zastosowania:

Problem 1
Projekt korzysta konfigurowalnych zasobów, np z bazy danych. W pliku kontekstu Springa określiłem potrzebne namiary: url, port, użytkownika hasło. Chciałbym mieć to jednak w oddzielnym pliku, żeby w razie potrzeby te namiary zmienić, bez przeglądania dużego xml'a z konfiguracją.

Rozwiązanie
W tym celu można użyć PropertyPlaceholderConfigurer, dzięki któremu odpowiednie namiary pobrane zostaną z oddzielnego pliku. W pliku kontekstu określa się lokalizację pliku z właściwościami, zawierającego pary klucz=wartość.
context.xml
<context:property-placeholder location="classpath:jdbc.properties"/>

<bean id="dataSource" destroy-method="close"
    class="org.apache.commons.dbcp.BasicDataSource">
  <property name="driverClassName" value="${jdbc.driverClassName}"/>
  <property name="url" value="${jdbc.url}"/>
  <property name="username" value="${jdbc.username}"/>
  <property name="password" value="${jdbc.password}"/>
</bean>
jdbc.properties
jdbc.driverClassName=org.hsqldb.jdbcDriver
jdbc.url=jdbc:hsqldb:hsql://production:9002
jdbc.username=sa
jdbc.password=root

Problem 2
Aplikacja, którą projektuję jest wdrażana na różnych środowiskach (np. na testowym i deweloperskim) i na każdym z nich łączy się z inną bazą danych. Nie chcę za każdym razem ręcznie aktualizować właściwości źródła danych.

Rozwiązanie
Pewne właściwości można umieścić w pliku pom.xml w sekcji properties. Włączenie filtrowania zasobów przez Maven'a, poprzez podanie ścieżki do katalogu z zasobami w sekcji resource spowoduje, że, jeśli któryś z plików w zasobach zawiera klucze takie jak ${jdbc.password}, to zostaną one zastąpione przez wartości właściwości z pliku pom.xml. W poniższym przykładzie podałem katalog src/main/resources, w którym znajduje się plik kontekstu.
context.xml
<bean id="dataSource" destroy-method="close"
    class="org.apache.commons.dbcp.BasicDataSource">
  <property name="driverClassName" value="${jdbc.driverClassName}"/>
  <property name="url" value="${jdbc.url}"/>
  <property name="username" value="${jdbc.username}"/>
  <property name="password" value="${jdbc.password}"/>
</bean>

pom.xml
<properties>
  <jdbc.driverClassName>org.hsqldb.jdbcDriver</jdbc.driverClassName>
  <jdbc.username>user</jdbc.username>
  <jdbc.password>pass</jdbc.password>
 </properties>
 <build>
  <resources>
   <resource>
    <directory>src/main/resources</directory>
    <filtering>true</filtering>
   </resource>
  </resources>
 </build>
Właściwości te mogą być różne dla różnych środowisk. Warto wtedy stworzyć profile mavena, a w nich właściwości specyficzne dla konkretnego środowiska:
<profiles>
  <profile>
   <id>prod</id>
   <properties>
    <jdbc.url>jdbc:hsqldb:hsql://production:9002</jdbc.url>
   </properties>
  </profile>
  <profile>
   <id>test</id>
   <properties>
    <jdbc.url>jdbc:hsqldb:hsql://testowa:9002</jdbc.url>
   </properties>
  </profile>
 </profiles>
Dzięki temu podczas budowania projektu można wybrać odpowiedni profil i automatycznie zostaną wybrane odpowiednie właściwości:
mvn clean install -P prod
Jeśli serwerem aplikacyjnym jest Tomcat, to warto wykorzystać profile do konfiguracji wdrażania aplikacji przez wtyczkę maven'a . Można też połączyć rozwiązanie pierwsze i drugie poprzez zamieszczenie we właściwościach pliku pom.xml jedynie nazwy plików dla PropertyPlaceholderConfigurer, by w zależności od profilu uwzględniany odpowiedni plik z właściwościami.