Příspěvky

16

Vývoj / Re: ako previest keySet() z hashMapy do pola Stringov

« kdy: 17. 04. 2011, 00:10:53 »

Spravne:
String[] x = (String[]) hs1.toArray(new String[0]);

Len doplním, že máš 2 možnosti:
1) String[] x = hs1.toArray(new String[0]);
2) String[] x = (String[]) hs1.toArray();

V prvom prípade už nie je nutnosť pretypovávať.

17

Odkladiště / Re: IT certifikace: složitost a důležitost

« kdy: 16. 04. 2011, 12:51:50 »

Môžem hovoriť iba z vlastnej skúsenosti. Čo sa týka certifikátov, tak naša firma ich priamo podporuje - sú vybrané tie, ktoré ti preplatia. Dokonca máme pár takých, za ktoré, keď ich získaš, dostaneš prémiu (nič veľké, ale poteší).

Z pohľadu zamestnávateľa sa tu na fóre veľa rieši a hlavne urážajú tí ľudia, ktorí certifikáty majú. To nie je úplná pravda. Rozhodne ti to pomôže, aby si sa dostal na pohovor. Tam môžeš ukázať, čo vieš a čo nie. Poprípade v skúšobnej dobe (tam skôr, pretože pohovor je príliš krátky na preskúmania technických vlastností).

Druhý pohľad zamestnávateľa, ktorý poznám, je v pozícii dodávateľa. Naše ponuky väčšinou zahŕňajú aj certifikáty ľudí. Keď zákazník chce spravovať Oracle server, tak do ponuky dáme niekoho, kto má naň certifikát - na zákazníka to vplýva veľmi priaznivo. To isté sa týka iných technológií, poprípade bodyshopu. Preto sa to podporuje. Je rozdiel, ak firma A podá ponuku s neznámymi ľudmi a keď firma B podá ponuku s tým, že ti dá napr. Teradata Certified Master človeka. To veľakrát zaváži, a aj vďaka tomu sa dá podať vyššia cena.

Čo sa týka získavania certifikátu, tak odporúčam najprv to v praxi vedieť, robiť s danou technológiou a až potom ísť na certifikát. Samozrejme, na certifikát sa dá našprtať, ale to neodporúčam, pretože potom sa stane to, čo tu už bolo spomenuté - nebudeš to vedieť v praxi použiť a v skúšobnej dobe sa na to príde.

Prínos certifikátu - pre mňa bol prínos ten, že napriek tomu, že som s danou technológiou robil pár rokov, tak som sa dozvedel nové veci. Skôr z filozofického smeru (prečo to navrhli tak a nie opačne). Ale aj z praktického - pozrel som sa na veci, ktoré som každý deň neprogramoval. Osobne si myslím, že to zvýšilu moju produktivitu.

Celkom dlhý príspevok  - ak by si mal ešte nejaké otázky, pýtaj sa.

18

Vývoj / Re: Dotaz ohledně IDE, licencí a komerčního sw

« kdy: 13. 04. 2011, 10:07:40 »

Zalezi na konkretnom IDE. Kazde si vacsinou riesi tento problem po svojom. Napr. Visual C++ express umoznuje vyvijat komercne veci. Taka IntelliJ Idea v opensource verzii zakazuje vyvijat komercny softver. Ten mozes vyvijat iba v platenej. Takze si treba precitat vsetky veci ohladne daneho IDE.
Obecne by opensource IDE nemalo zakazovat vyvoj komercneho produktu, pokial nie je povedane inak - to jest, treba to explicitne zmienit v licencii alebo podmienkach pouzivania.

19

Odkladiště / Re: GPL modul pro komerční CMS

« kdy: 10. 04. 2011, 16:16:14 »

Dobra otazka. Zalezi na viacerych faktoch.
1) Mienite to rozsirovat(predavat) hromadne, ci to robite len pre jedneho klienta?
2) Je ta licencia cisto GPL, neda sa zohnat s LGPL licenciou?
3) Trochu zalezi, ktora verzia GPL to je (1,2,3).
4) Dost zalezi, aky modul to bude. GPL v tom nie je uplne jasna. Ak to ale bude formou pluginu, tak by stacilo ten plugin licencovat pod GPL a zvysok systemu moze byt uzavrety. Akurat v instalacii dodate tento extra plugin do systemu.

Bod 4 je moj nazor, neviem o ziadnom pripade, kde by sa to sudne riesilo, takze korektnost moze urcit len a len sud.  Napriek tomu si myslim, ze by to malo odolat. Zalezi vsak na predchadzajucich bodoch.

20

Odkladiště / Re: Desetilety objednal placene sluzby, co s tim?

« kdy: 08. 04. 2011, 17:03:23 »

Skus sa pozriet na http://vat.pravda.sk/soi-vydala-vlastne-stanovisko-v-kauze-60-eurovych-faktur-pk1-/sk_vkom.asp?c=A101007_021659_sk_vkom_p35. Je to podobny pripad (sice na Slovensku, ale podobne problemy boli aj v Cesku).

21

Vývoj / Re: Agilné programovanie v praxi

« kdy: 06. 04. 2011, 11:26:06 »

@astarus
Je toho plný internet napr. http://en.wikipedia.org/wiki/Agile_software_development.

To je prave ten problem - je toho plny internet. Ale nikde nemas presnu definiciu toho, co tam patri a co nie. Je tam obrovska seda zona. Ale snad sa to casom vykrystalizuje (tak za 10 rokov

Co su naopak neskutocna otrava - planing meetingy v prvy den iteracie. Je to snaha o rozkuskovanie planovanej dodanej funkcnosti na backlogy a tasky. Pomocou pokra kazdy hodnoti narocnost backlogu/tasku (v cloveko-hodinach). Je to neskutocne otravny den, ked sa skoro vobec neprogramuje (uz sa stalo, ze sme planing meeting koncili o 17:00) a snazime sa predvidat, co a ako sa bude kodit.

Neviem, ake velke mate projekty, ale u nas tie mitingy nie su zdaleka take dlhe. Minimalne tam nechodi kazdy, ale len hlavni a potrebni ludia. Vacsinou mame za 2 hodiny koniec. Sice je pravda, ze som uz zazil aj poriadne zabite planovanie, ale to bolo hlavne tym, ze tam bol kazdy a kazdy sa mohol vyjadrovat. Mensia diktatura obcas nezaskodi

22

Vývoj / Re: Agilné programovanie v praxi

« kdy: 06. 04. 2011, 10:51:30 »

Dobré je si ujasniť čo to vlastne to Agílne programovanie je.
...
Do tohto klobúka potom spadá, napríklad SCRUM, XP, Continuous Integration, Iteration a iné metodiky, ktoré môžu a nemusia pomôcť vo vývoji SW v danej spoločnosti.

Suhlasim s tym, ze tazko povedat, co to je. Osobne som sa stretol so Srumom, test driven develoment, ...

Scrum ma velku vyhodu pre veduceho timu, pretoze za par minut ziska prehlad o tom, co sa robilo minuly den. Pre ostatnych ludi mi pride, ze to nema az taky velky prinos.

Test driven - pekna idea, ale ked sa zneuzije, tak je problem. Testy urcite patria k vyvoju, ale pokial ma niekto nuti najprv napisat testy a a z potom navrhnut interface, tak kdesi je chyba... Na druhej strane tento pristup pomaha, pokial nemas dobru analyzu - teda, je dobry, aj ked ju mas, ale ked ju nemas, tak ta prinuti sa zamysliet nad tym, co by tam malo byt a ako by to malo fungovat.

Continues integration - som este nepocul, ze by to malo spadat do AP. Tak ci tak to beriem ako zaklad na projekte, kde je ostro viac ako jeden vyvojar. Je to neuveritelna pomoc a stoji to minimum prace.

Ak mas konkretnejsie otazky, pytaj sa

23

Odkladiště / Re: Máte zkušenosti s ITIL, ISO apod.?

« kdy: 02. 04. 2011, 15:52:49 »

No to jo, to je jasný. Ale chybí mi nějaké obecné vodítko. Např. u eventů ITIL detailně rozebírá jejich korelaci, jak se z eventu stane incident (v jaké fázi a jakým způsobem) atd. Tady mi to trochu chybí. (to bude asi určitě jenom moje neznalost, prostě jsem na to zatím asi v literatuře nenarazil)

Bohuzial nic take neexistuje. Navod na to by bol prilis obecny. Vzdy zalezi len a len na vasej firme a jej situacii. Jedine, co mozes, je sa pozriet, ako to implementuje nejaka ina firma a dovod, preco to tak implementuje.

24

Odkladiště / Re: Máte zkušenosti s ITIL, ISO apod.?

« kdy: 02. 04. 2011, 12:43:36 »

Incident nemusí ohlašovat jenom zákazník. To může být i interní zaměstnanec.

Zabudol som napisat "napriklad"

Není mi jasné, jestli existují nějaká kritéria na to, kdy už by bylo záhodno vyplnit problem record. Nemělo by to přece záležet na tom, že si někdo řekne "už to padá nějak často"...

To je prave ono - ziadna norma/standart ti nepovie, ako to spravit, iba, ze to mas spravit. Preto to zalezi na tebe. Na tom, ake mate s tym vo firme skusenosti. Takze tieto kriteria si musis nastavit sam. Podla procesov, ktore uz mate.

25

Odkladiště / Re: Máte zkušenosti s ITIL, ISO apod.?

« kdy: 02. 04. 2011, 10:29:44 »

Co sa tyka tychto standartov, tak skusenosti mam z dvoch firiem, kde som pracoval (jedna mala ISOxyz, druha CMMI3). Jedine ITIL som nezazil na vlastnej kozi, len ho poznam trochu teoreticky. Na druhej strane - vsetko je podobne - ak mas rozumnu strategiu v ramci firmy, tak mozes dostat vsetky tieto certifikacie celkom zadarmo.

Hlavní rozdíl mezi PM a IM vidím v tom, že IM má jasnej vstupní bod - volá zákazník, zaměstnanec vyplní hlášení, nějaká sonda spustí event, že  něco není v daných mezích atd. Oproti tomu PM je definovanej (opět cituju) jako "the unknown cause of one or more incidents", takže mi trochu chybí nějaký jasně měřitelný vstupní bod - je jasný, že někdo s hlášením problému přijde (např. service desk, když se nějaký incident stává často), ale neumím si představit nějaké obecné kritérium, podle kterého by se dalo přesně stanovit, kdy už se má problém vytvořit.

Podla toho, co viem (opakujem, s ITIL nemam prakticke skusenosti), tak incident je, ked zakaznik najde chybu - napr. server nam po novej dodavke kniznice X spadol.
Incident sa problemom stava, ak sa ti to nepodari standartnym postupom vyriesit. Resp. podrobnou analyzou incidentu zistis, ze kniznica X vo verzi 3.14 sa nema rada s kniznicou Y vo verzii 2.18. Nevies preco presne, mas problem. Ak zistis aj presnu pricinu, tak stale ju nemusis odstranit, takze mas problem - popripade niektori to nazyvaju feature .