Thursday, February 27, 2014

Poticanje ljudi na odlazak iz Hrvatske - piljenje grane na kojoj sjedimo...

Često čujem kako netko potiče ljude da se javljaju na oglase za poslove van Hrvatse te ih dodatno potiču na taj korak odlaska. Moram priznati da me to većim dijelom zabrinjava, čak užasava, a jednim malim dijelom i nasmijava. Zadnji primjer, koji me je na kraju i nagnao da napišem ovaj post, je sljedeći:


Moram odmah istaknuti kako se u ovom konkretnom slučaju radi o računalnim stručnjacima, no sve se to može, a i mora, primjeniti i na ostali visoko obrazovani kadar.

Dakle, zbog čega me to zabrinjava, a i nasmijava? Pa, da bi se to shvatilo nužno je prvo razjasniti različite perspektive iz kojih se to može gledati, ili drugim riječima, različite dionike (engl. stakeholders). Naime, o perspektivi ovisi što je istina, i kao što je odmah jasno, očito je da postoji više istina. Pri tome, nepobitna je činjenica kako se svaki od dionika mora voditi svojim vlastitim interesima. To je na kraju krajeva, jedino racionalno ponašanje.

Dakle, dionici, odnosno perspektive su:
  1. Osoba koja odlazi van.
  2. Osobe/ljudi koji ostaju u Hrvatskoj.
  3. Osoba koja potiče ljude na odlazak van. Ova kategorija se nadalje može podijeliti na one koji potiču i vani su, te oni koji potiču i u Hrvatskoj su.
  4. Tvrtka koja je vani i traži zaposlene.
Ostatak teksta ću, dakle, podijeliti prema svakoj od tih dionika, te sagledati situaciju iz perspektive svakog od njih. Ključni dio je druga točka, otisnuta masnim slovima, i ako ne čitate pretjerano detaljno ovaj post, ipak bi preporučio da na tu točku obratite pozornost jer je u njoj suština ovog posta.

Primjetite inače da mi klasifikacija nije savršena jer postoji određeno preklapanje. Međutim, nemam niti volju niti namjeru učiniti tu klasifikaciju savršenom. Bitna je poanta koju želim poručiti i mislim da će ova klasifikacija za to biti sasvim odgovarajuća.

Osoba koja odlazi van

U ovom slučaju, nemam što komentirati. Budući da svatko gleda svoj interes, tako i svaka osoba može i mora za sebe odlučiti i odvagati koje su najbolje opcije i postupiti shodno tome.

Možda bi samo kao malu digresiju  mogao reći kako je problem da odlaze van osobe kojima je i u HR dobro, a one kojima je u HR loše, ostaju u HR. Naravno da to nije apsolutno pravilo, ali, mislim da prosjek jako dobro reflektira to što sam rekao. I ta činjenica je bitna, ali tek u kontekstu iduće točke...

Ljudi koji ostaju u Hrvatskoj

Ovdje bi se moglo napraviti daljnje raslojavanje i detaljnija analiza, ali nema potrebe jer stvar je vrlo jednostavna. Naime, ovu grupu bi najbolje mogao opisati kao ekipu koja sjedi na grani, nekolicina reže tu granu, a ova grupa se ponaša kao da ih nije briga. U biti, i nije ih briga jer nemaju pojma.

Koji su razlozi zašto to tako tragično doživljavam:

  1. Novci poreznih obveznika su utrošeni na školovanje tih ljudi, i to ne mali. Dakle, porezni obveznici bi mrali biti zabrinuti kamo se bacaju njihovi novci!
  2. Stručni, obrazovani ljudi su ono što pokreće moderne ekonomije. Hrvatska, odlaskom takvih ljudi, ostaje na ljudima sa srednjom stručnom spremom i prema tome osuđena je na propast.
  3. S takvim odljevom trebali bi se zabrinuti tko će školovati buduće generacije, a također, trebali bi se zabrinuti tko će nas u budućnosti liječiti, ili tko će nam  zarađivati penzije.
  4. Sposobni ljudi čine okolinu koja napreduje, i vuče sve za sobom. Ako nema sposobnih ljudi, nema ni napretka okoline.
Mislim da su to vrlo jaki razlozi zašto nikome normalnome ne bi smjelo pasti na pamet da potiče ljude na odlazak van. 

Kao jedan zanimljiv primjer spomenut ću moj rodni grad, Viroviticu. Naime, iz Virovitice mnoštvo srednjoškolaca je otišlo na studij u Zagreb, Osijek, Rijeku. No, jako malo se i vratilo nazad. To je slučaj barem od kad sam ja otišao na studij. Rezultat je taj da Virovitica, kao i velika većina Hrvatske, stagnira i vrlo vjerojatno se nalazi u fazi kada povratak više nije moguć. Dakle, to će se desiti i Hrvatskoj.

Osobe koje potiču na odlazak i nisu u Hrvatskoj

Tu nemam što dodati, osim da tim ljudima nije ni u džep ni iz džepa to što će tamo netko iz neke države otići, i na taj način osiromašiti tu državu. Koji su motivi te ekipe, teško je reći.

Osobe koje potiču na odlazak i jesu u Hrvatskoj

Za njih mogu reći sve što sam rekao i za one koji ostaju u Hrvatskoj, jedino što su ovi oni koji pile granu i/ili navijaju da se grana što prije prepili. Dakle, šutljiva većina nanosi štetu svojom neaktivnošću i nerazumijevanjem, ovi nanose najveću štetu i trebalo bi ih javno osuditi u novinama. No, kad smo već kod toga, ni novinari previše ne kuže.

Trtvke koje su vani i vrbuju 

One imaju i te kakvu korist od ljudi koji dolaze jer, obično, u svojoj okolini ne mogu pronaći dovoljno kadra. To je sigurno tako za Silicijsku dolinu, Irsku, ali i niz drugih država/regija gdje se nalazi skoncentrirana nekakva industrija, a lokalna okolina nije u mogućnosti pružiti dovoljno ljudskih resursa.

Sunday, February 23, 2014

Kernel upgrade to 3.13.3-201 and VMWare Workstation...

I just started VMWare for the first time after upgrade and restart into kernel 3.13.3-201, and it didn't work. Well, I already got used to it. Anyway, the fix was very quick. I found a patch in a post on VMWare forums, downloaded it and applied it. The application process is a bit more manually involved that with the previous patches. You need to:

  1. Switch to root user.
  2. Go to the /usr/lib/vmware/modules/source directory
  3. Unpack vmnet.tar using tar command.
  4. Enter into newly created vmnet-only directory
  5. Apply patch (patch -p1 < path_and_name_of_unpacked_patch_file). Patch shouldn't make any noise, only patched file is displayed.
  6. Go one level up (exit vmnet-only directory)
  7. Rename existing vmnet.tar into something else, just in case.
  8. Create new vmnet.tar (tar cf vmnet.tar vmnet-only)
  9. Start vmware
And that's it...

Saturday, February 22, 2014

Messing up Zimbra upgrade, a.k.a. dangerous --platform-override option...

You know that Zimbra's installer has --platform-override option that enables you to install Zimbra on unsupported platforms, like CentOS. Well, it also allows you to mess up things. Namely, I downloaded Zimbra for RHEL6, but was upgrading an existing installation on CentOS5. And I didn't noticed anything unusual until upgrade process failed! It failed very early with an error message from loader that it couldn't start perl binary. Namely, the error message I got, was similar to:
/usr/bin/perl: symbol lookup error: /opt/zimbra/zimbramon/lib/i386-linux-thread-multi/auto/IO/IO.so: undefined symbol: Perl_Tstack_sp_ptr
It wasn't exactly that one, but similar! Well, I was surprised because Zimbra's upgrade process is good and robust, and I had never problems with it, but since I had some local customizations on my installation I suspected those to be the cause. So, I ended up by copying CentOS' Perl installation into Zimbra tree. This process wasn't actually so easy to do and that should've warned me that something is terribly wrong, but I continued nevertheless. But, when I managed to pass that point, the next one finally made me realize the mistake. Namely, mysql binary required Glibc 2.7, while in CentOS 5 is some earlier version. Now, I knew what mistake I've made.

Here is also a point I realised that I'm facing a long night trying to recover Zimbra installation!

So, I've downloaded the correct version of Zimbra, the one I intended to upgrade to, manually installed it using rpm tool, and then restarted upgrade process with:
/opt/zimbra/libexec/zmsetup.pl
And here my problems continued. Namely, the upgrade script correctly figured that I'm trying to upgrade, it also correctly figured the old and the new version, but it stuck on starting mysql server. After some time I managed to figure out where the problem is, namely, existing mysql database has password while the installation process assumes there isn't one. So, it couldn't determine if mysql was started or not, and everything stalled. I lost some time trying to make database not to ask for the password, and even though I managed to do something, luckily, in the mean time I stumbled on the following Wiki page:
Recovering from wrong platform upgrade
I made it large because it really got me out of the problem. It is written for version Zimbra version 5, but it works on 7, too. In a nutshell, you install the old Zimbra versions you had and then start from there with the idea of making a rollback. BUT, BIG WARNING, this is possible only if your localconfig.xml file is intact. In my case, I erased it, but the upgrade process saved a copy which I was able to recover! I had some additional problems while testing installation as suggested byt the Wiki page, but all of them were related to the tweaks I did to my installation of Zimbra, i.e. binding Zimbra to a single IP address.

What have I learned

Well, first and foremost, do a backup before doing an upgrade. Yes, I know it was stupid, and beginner's, mistake, but as I've said, Zimbra's upgrade process is really good, at least for me. The real reason I didn't do it was that it takes several hours to make it. If I had copy, I would revert to that copy, and I would only need to fix RPM database. So, to avoid the same thing happening again, now I did make a backup process which rsync'es all of Zimbra tree to an alternative location every day.

Next thing is, localconfig.xml file is extremely important, so I did additional backup of that file, too. Note that in the file are all passwords so, it's also critical from the security perspective!

Also, I would suggest that Zimbra adds checks into installation script to guard against mistakes like the one I did. It turns out, after some googling, that there are a lot more other posts with the similar problems. This can be easily done for CentOS/RHEL with appropriate requirements in RPM packages.

And for the end, here is one other story about failed Zimbra upgrade which I find interesting.

Friday, February 21, 2014

GnuCash - Troškovi na kreditnoj kartici

Vođenje troškova koje se ostvaruju putem kreditne kartice se ispostavilo kao najzahtjevnije. Postoji više načina na koji se to može obaviti, ali ja sam se u konačnici odlučio za detaljniji način, tj. onaj koji omogućava detaljnije vođenje troškova. Komplikaciju predstavlja činjenica kako nije moguće voditi troškove u različitim valutama unutar jedno računa (odnosno stavke kako sam ponekad pisao), bar ja ne znam kako bi to učinio. U tom smislu, odlučio sam se za zasebno vođenje evidencije kunskih te troškova u eurima.

Stvaranje računa

Dakle, kao prvi korak je kreirati račune, odnosno stavke, za kreditne kartice. To je relativno jednostavno, treba kliknuti na desnu tipku miša negdje unutar prozora s računima/stavkama te odabrati opciju New Account... i u prozoru koji se pojavi ispuniti polja na način prikazan sljedećom slikom:


Pod naziv je upisano Kreditne kartice, označena je opcija Placeholder što znači da se radi samo o računu koji sadrži druge račune ali neće u njemu moći biti upisivane stavke. Pod tip računa (Account Type) označeno je Credit Card i konačno, pod Parent Account, je označeno da se radi o novom vršnom računu. Sada je potrebno kreirati pojedine račune za Kunske troškove te troškove u Eurima. Opet je potrebno kliknuti na desnu tipku miša i odabrati opciju New Account... te potom ispuniti podatke kako je to prikazano na sljedećoj slici:



Ovim se stvara račun za MasterCard koji dolazi na naplatu u kunama. Primjetite kako je odabran tip računa Credit Card te je postavljen unutar stavke Kreditne kartice. Slično je i za Eure:



S tim da je u ovom slučaju odabrana valuta EUR (Euro).

Konačno stanje je prikazano sljedećom slikom:



Upisivanje troškova

Pretpostavimo kako smo s kreditnom karticom platili gorivo koje nas je koštalo 400Kn te je kupljeno na dan 29.11.2013. Dodatno, dana 4.12.2013. bili smo u nabavci te smo kupili hrane za 200kn. Te dvije stavke bi upisali pod račun MasterCard - Kunski troškovi na sljedeći način:



Primjetite kako je u koloni Transfer upisano na što se odnosi trošak. Dakle, kada sam kupio gorivo i platio ga kreditnom karticom, stavio sam da se radi o trošku za gorivo. Takav način upisivanja vezan je uz moju odluku kako želim voditi detaljne troškove kreditne kartice, tj. na ŠTO su novci potrošeni, a ne samo koliko je potrošeno. Kao zadnju stvar, primjetite da se trošak upisuje u kolonu Charge.

Upisivanje deviznih troškova je gotovo identično, jedino što se troškovi ne upisuju u kunama već u Eurima.

Naplata troškova

Kada vam banka konačno obračuna troškove i izvrši plaćanje onda je potrebno provesti postupak "rekonsilijacije" (ili kako god se to već zove u bankarskim krugovima). Naime, novci se povlače s vašeg tekućeg računa (ili ih uplaćujete u banci) te je potrebno obaviti tu transakciju. To se obavlja na sljedeći način

Prvo, kliknite desnom tipkom na račun kreditne kartice za koju je došla naplata. Pretpostavimo da je to kunski MasterCard. Na desni klik, otvorit će se izbornik unutar kojega je potrebno odabrati opciju Reconcile:




Kada odaberete tu opciju otvara se novi prozor. Unutar njega potrebno je odrediti datum kada se vrši naplata (ili obračun troškova) te suma koja je do trenutka obračuna učinjena:


U mom slučaju, odabrao sam datum 20.12.2013 jer na taj dan je stigla naplata te mi je sam GnuCash odredio da sam do tog trenutka napravio trošak od 600Kn. Ovom prilikom treba reći kako postoji razlika između datuma kada se vrši obračun (recimo, meni je to 10. u mjesecu) i datuma kada se vrši plaćanje (to je 20. u mjesecu). Ako ste upisali pod "Statement Date" datum plaćanja, a između datuma plaćanja i formiranja obavijesti je bilo troškova, oni će greškom također biti uključeni u naplatu. Dakle, pripazite na to. Možda je ipak najbolje upisivati datum formiranja troška, a ne kako sam ja napravio datum naplate.

Nakon što potvrdite informacije o datumu obračuna te konačne sume pritiskom na OK, otvara se novi prozor unutar kojega trebate odabreti koje sve stavke dolaze na plaćanje:


Ono što trebate učiniti je u desnom dijelu odabrati stavke koje se naplaćuju. Primjetite da svaka stavka, na kraju, ima kolonu R. To su "checkboxovi" koje treba selektirati. To morate napraviti tako da na kraju pokrijete sav trošak koji dolazi na naplatu, dakle svih 600kn. Razlika, koliko je još preostalo, navedena je u donjem desnom kutu, u retku "Difference". U našem slučaju, treba odabrati sve stavke, međutim, ako je nakon formiranja obavijesti bilo novih troškova, onda naravno nećete te nove troškove odabirati. Kada ste napravili odabri, stanje je sljedeće:


Primjetite dvije stvari. Prvo, razlika je 0 jer smo pokrili svu sumu koja dolazi na naplatu, i drugo, zelena tipka u traci s alatima je sada omogućena. Naime, tu zelenu tipku treba odabrati kako bi se nastavilo u sljedeći, i zadnji, korak:


U zadnjem koraku treba odabrati odakle se pokrivaju troškovi koji su načinjeni na kreditnoj kartici. U mom slučaju, troškovi se pokrivaju s tekućeg računa pa sam ja odabrao u polju "Transfer From" tekući račun, dok sam u polju "Transfer To" odabrao kunski kreditni račun. Klikom na OK, obavlja se transakcija, i cijeli postupak je završen. Sada situacija izgleda ovako:


Drugim riječima, na kunskom MasterCardu nemam nepodmirenih troškova, dok mi je tekući račun "tanji" za 600kn.

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)

Blog Archive