Portál AbcLinuxu, 8. května 2025 19:13
GitHub na svém blogu zveřejnil vývoj popularity programovacích jazyků používaných na GitHubu v letech 2008 až 2015. Použité programovací jazyky ve veřejných i soukromých repozitářích byly rozpoznávány pomocí open source knihovny Linguist. V současné době je na GitHubu nejpopulárnějším programovacím jazykem JavaScript. Na dalších místech jsou Java, Ruby, PHP, Python, ...
Tiskni
Sdílej:
Between 2008 and 2015 GitHub gained the most traction in the Java community, which changed in rank from 7th to 2nd. Possible contributing factors to this growth could be the growing popularity of Android and the increasing demand for version control platforms at businesses and enterprises.Tak me napada, jestli do toho ranku zapocitavaji i github enterprise a jestli je opravdu tak popularni ..
dost blbe ked prgam v tak nepopularnych jazykoch ako je c++ ci v hadovi...
a je dokonce nad C#Mozna v teto analyze. U hodnoceni vysledku c# je treba si uvedomit, jaky maji vztah programatori pisici v tomto jazyku k opensource a specialne ke git. c# je mozna pod c++ v teto analyze, ale v komercni sfere tomu bude presne naopak. Zajimave by bylo porovnat opensource projekty obecne a ne jen projekty, ktere jsou na github.
lepší uživatelské rozhraníTo je otazka nazoru. Osobne mi prijde github docela luxusni.
odtud jednodušší cesta k prodeji aplikacíToto bohuzel neumim posoudit.
The rank represents languages used in public & private repositories, excluding forks, as detected by Linguist.
Navic mam rad zpetnou kompatibility, mam tu skripty co jsem psal kolem roku 2000 a funguji i na nejnovejsim Perlu.
V šestce?
a toho, ze Perl se porad pouziva jako pomocny jazyk i v projektech, ktere jsou temer cele v Python/Ruby...
Já ho takhle používám i na projektech v Javě
Ale kdyby to byl projekt v Pythonu, tak asi zatnu zuby a napíšu i ten zbytek v Pythonu. Přišlo by mi zvláštní mít v jednom programu Perl i Python.
Super, Perl na devatym misteV roce 2011, kdy se propadl mimo graf.
Většina lidí chodí do práce a platí daně. Dá se z toho vyvozovat, že jsou to populární činnosti?
Ten JavaScript mě trochu překvapuje – dá se čekat, že se bude používat, protože hodně lidí musí dělat pro web a v prohlížečích nic jiného nefunguje – ale že v něm bude většina zdrojáků? Měl jsem pocit, že hodně lidí od JS utíká k jiným jazykům (CoffeeScript atd.) a do JS to jen kompilují.
Rozhodně tisíckrát lepší než Javy, C#py a podobné ptákovinyAno, pokud jde o větší chaos nebo o chyby přístupu do paměti.
generika jsou velmi, velmi, velmi omezená náhradaTo platí i naopak – šablony jsou omezená náhrada generik. Například se šablonami nemůžete provádět polymorfní rekurzi – tj. generická funkce volá sama sebe, ale typový argument je jiný (důvod, proč to nejde, je, že typové argumenty neznáte v době kompilace).
Pes
podtyp Zvíře
pak IEnumerable<Pes>
je podtyp IEnumerable<Zvíře>
– AFAIK obdobná věc v C++ nefunguje.
Nevím, co přesně dělá IEnumerable
, ale obecně takhle dědičnost u generik fungovat nemůže. Pokud mám např. generickou třídu Třída<T>
s metodami T getData()
a void setData(T data)
a mám typ A
a jeho podtyo B
, tak nemůžu říct, že Třída<B>
je podtyp Třída<A>
, protože tenhle „podtyp“ nemůžu použít místo jeho „nadtypu“ – nemůžu na něm totiž zavolat setData(A)
, protože podporuje jen setData(B)
.
obecně takhle dědičnost u generik fungovat nemůže.To je pravda.
IEnumerable<T>
je analog Iterable<T>
z Javy – je kovariantní v T
, tedy uvedené přetypování je korektní.
Mj. C# je momentálně více omezený než Java, neboť pro hodnotové typy to nefunguje. Na rozdíl od Javy IEnumerable<int>
v C# neobsahuje boxované integery, daní ovšem je, že to nemůžete přetypovat na IEnumerable<object>
. Pokud bude Java závádět hodnotové typy, jsem zvědav, jak se s tím vypořádá – je to volba mezi výkonem a flexibilitou.
#include <iostream> template<class T> class Variance : public Variance<typename T::BaseType> { T t; public: void xx() { t.x(); }; virtual void vx() { t.x(); }; }; template<> class Variance<void> { }; class Zvire { public: typedef void BaseType; void x() { std::cout << "Zvire" << std::endl; }; }; class Pes : public Zvire { public: typedef Zvire BaseType; void x() { std::cout << "Pes" << std::endl; }; }; int main(void) { Variance<Pes> vp; Variance<Zvire>& vz = vp; vz.xx(); vz.vx(); reinterpret_cast<Variance<Pes>&>(vz).xx(); dynamic_cast<Variance<Pes>&>(vz).vx(); return 0; }
T
vyskytuje pouze jako návratová hodnota metod.
Pokud se nepletu, tak Variance<Pes>
obsahuje nejen instanci Pes
, ale i instanci Zvíře
, a po přiřazení do vz
se začne používat instance Zvíře
místo instance Pes
.
Tento trik sice umožní bezpečné přetypování (dokonce Pes
by ani nemusel být podtyp Zvíře
), ale IMO nepřináší výhody známé z Javy nebo ze C# – například při implementaci kontejneru by to moc nepomohlo, neboť i po přetypování chce uživatel kontejneru pracovat se stejnými prvky jako před přetypováním.
Nabízí se tedy použít ukazatele nebo reference, ale i tak tu zůstávají určité problémy – například se specializací nebo s tím, že kompilátor C++ neumí zkontrolovat korektnost přetypování.
toto sa pocita?Castecne ano, nicmene to tady neni asi hlavni - pokud k reseni potrebuje podobny pristup, je lepsi to udelat jinak a jinym zpusobem, nebo muzete skoncit u vetsich projektu s neprehlednym a slozite udrzovatelnym kodem.
Jejich Result<T, E>
vypadá zajímavě a možná by tím šly nahradit výjimky. Ale čím se dá nahradit blok finally
, try, který automaticky zavírá zdroje nebo hierarchické zpracování výjimek (na určité úrovni je nechci řešit, pošlu je výš a zpracuji až tam), nebo dědičné výjimky (mohu odchytávat obecnější nadtyp výjimek místo konkrétních)?
Otázkou je, zda to potřebujete, když máte destruktor (traitAle čím se dá nahradit blok
finally
, try, který automaticky zavírá zdroje
Drop
).
Ja, webový vývojár ktorý robí v C++ menej než 5% času skúsim opísať prečo ho používam (hmm, mám rád je asi moc silné).
Vo voľnom čase (i keď nie zadarmo) robievam rôzne špecializované zariadenia. Najnovšie to bol monoboard, ale robil som aj zložitejšie veci napr. dotykový jukebox (ospravedlňujem sa za kvalitu, nemal som vtedy lepšiu kameru). Z open source vecí mám zverejnené zdrojáky mierne upraveného emulátora segy genesis, virtuálnu klávesnicu pre Qt (zdrojáky) ... V C++ tiež programujem mikrokontroléry (ukážka). Nemám problém písať v C++ pre 8-bitový mikrokontrolér s 256 B RAM a 4 kB flash.
C++ patrí spolu s C k najuniverzálnejším jazykom. Hoc to mnoho ľudí bude popierať, má mnoho mnoho dobrých vlastností. No a tiež mnoho mnoho zlých vlastnotí. Vlastne dalo by sa povedať, že má mnoho mnoho vlastností. Vlastne až moc vlastností. A to je tak trochu problém, lebo sa v tom už od C++0x nevyzná ani divá sviňa.
Teraz ma kľudne ukameňujte, ale za najväčšie pozitívum považujem správu pamäte. Prakticky neobmedzený stack, RAII, zvyšok si môžem spravovať sám. Bude to znieť divne, ale omnoho ľahšie urobím memory leak v javascripte než v C++. U javascriptu si nikdy nie som istý, či mi nezostal niekde visieť handler, kvôli ktorému GC nemôže vyčistiť už nepoužívané objekty.
Šablóny sú turing complete. Videl som rôzne divné programy napísané len pomocou šablón. Tu je tetris, ktorého logika je napísaná pomocou šablón. Teoreticky by to mohla byť killer feature ako v lispe ... nebyť šialenej sytaxe pri ktorej má človek chuť vraždiť.
STL sa dá slovami ťažko popísať, ale kým sa v tom človek nehrabe je to vcelku znesiteľné. Podobným štýlom je písaná aj knižnica boost.
C++ je možno za zenitom, ale nevidím žiaden jazyk ktorý by ho mal nahradiť v zariadeniach s obmedzenými prostriedkami. Na desktope tu zopár kandidátov je, ale chýbajú mi napr. bindingy pre Qt / QML. Písať UI v html sa mi vážne nechce.
Bude to znieť divne, ale omnoho ľahšie urobím memory leak v javascripte než v C++. U javascriptu si nikdy nie som istý, či mi nezostal niekde visieť handler, kvôli ktorému GC nemôže vyčistiť už nepoužívané objekty.Jakože v C++ můžete objekt uvolnit, i když na něj existují ukazatele? To mi zrovna výhodné nepřijde.
Nie len možné, ale v prípade cyklických závislostí bez GC nutné.
Z vlastných skúseností by som povedal, že zabudnúť referencie kvôli ktorým stále rastie množstvo obsadenej pamäte v jazyku ako javascript je omnoho jednoduchšie než hrabať tam kam nemám v C++.
Momentálne programujem tak 60% v javascripte a 35% v pythone, zvyšných 5% sú práve hobby projekty v C++.
Uklizeni handleru, observeru apod musi vzdy resit programator.
Nepletiem. Upratovanie handlerov sa dá riešiť v deštruktore. Takto to má riešené napr. Qt. Stačí zavolať delete na niektorej strane spojenia a zruší sa celé spojenie.
Qt má mimochodom upratovanie riešené pomocou QObjectov. Každý QObject môže mať nastaveného vlastníka (parent), ktorý sa môže počas behu meniť. QObjecty tvoria stromovú hierarchickú štruktúru, zavolaním delete na nadradenom objekte (napr. na okne) zavolá kaskádovo delete na každý objekt v štruktúre (napr. toolbar, tlačidlá ...). Problémom sú weak pointre (tu musím trochu ponadávať na C++), kvôli ktorým musím buď zasrať API, alebo vymyslieť presne pravidlá zodpovednosti za uvoľnenie prostriedkov.
Nechcem tým obhajovať C++. Nemám ho rád. Podľa mňa to nabaľovaním vlastností prehnali.
Teda možno sme sa nepochopili. Mám napr. databázu používateľov a okno na úpravu používateľa:
auto userEditWindow = new UserEditWindow(this, database->getUserById(userId)); QObject::connect(userEditWindow, SIGNAL(userDataChanged(const User&)), database, SLOT(saveUser(const User &)); QObject::connect(userEditWindow, SIGNAL(closed()), userEditWindow, SLOT(deleteLater());
Ak zatvorím okno zavolá sa metóda deleteLater, ktorá zničí objekt po návrate do event loopu. Zároveň zruší spojenie s databázou, takže nemusím volať príslušný disconnect.
Metódy connect a disconnect sú statické. O upratovanie sa nemusí starať programátor. QObject automaticky pri zrušení objektu zruší všetky spojenia v ktorých sa daný objekt vyskytuje buď ako zdroj alebo príjemca.
Nie je to v statických metódach, ale v deštruktore QObjectu. Autor je uvedený ako "Qt by Nokia".
QObject::connect(userEditWindow, SIGNAL(userDataChanged(const User&)), database, SLOT(saveUser(const User &));
Toto volanie aktualizuje zoznam príjemcov v objekte userEditWindow a zároveň zoznam odosielateľov v objekte database. Nič magické v tom nie je. Dá sa to napísať v skoro každom jazyku.
Na základné otázky sa mi nechce odpovedať.
Tak potom nechápete čo chcem povedať.
Ešte raz: ľahšie urobím memory leak v jazyku ktorý väčšinu správy pamäte rieši za mňa cez GC a občas si musím niečo po sebe upratať než v jazyku, v ktorom musím za sebou upratovať vždy. Možno som v tomto špecifický, ale na rutinné veci nezabúdam, ale na to čo robím občas zvyknem zabudnúť.
Zvyšok diskusie bol o handleroch. Ja tam zase hovorím, že ak používam v Qt signály a sloty tak sa nemusím o ne vôbec starať. Stačí ak zruším jednu stranu spojenia a o zvyšok sa postará QObject sám (každý objekt ktorý sa používa vo volaní connect musí byť potomkom QObject-u). Zvyšok poriešim automatickým čistením podľa hierarchie (odstránim parenta a celá kaskáda QObjectov sa korektne dealokuje, odbinduje ...), opustením bloku (nie všetko musím alokovať cez new) a na ten zvyšok už musím použiť čítače referencií (QWeakPointer, QSharedPointer).
Handlery si môžem čistiť aj v iných jazykoch. Zvyčajne tam nie je žiadna konvencia kde upratovací kód strčiť na rozdiel od C++ kde sa to logicky hodí do deštruktora. Toť asi jedna pozitívna vlastnosť, zvyšok je v C++ veľký bordel.
To je v podstate jediny zpusob jak leakovat pamet treba v Jave
Na tom sa zhodneme. Ja som chcel vyzdvihnúť, že deštruktor v C++ sa dá využiť na upratanie niektorých zoznamov (napr. zoznam spojení objektov), takže keď zruším objekt, ktorý nepotrebujem zruší sa mi jeho spojenie s ostatnými objektmi. V jave / javascripte / ... by som mal stále živú referenciu na daný objekt a nemohol by sa dealokovať. Samozrejme môžem v C++ urobiť mnoho ďalších závažných chýb prístupu k pamäti, ale ako som napísal mne osobne sa takéto niečo stáva menej často než zabudnutá referencia pri handleroch.
takže keď zruším objekt, ktorý nepotrebujem zruší sa mi jeho spojenie s ostatnými objektmi. V jave / javascripte / ... by som mal stále živú referenciu na daný objekt a nemohol by sa dealokovať.Nejde použít slabou referenci (např.
WeakReference<T>
v Javě)?
coz se ohromne hodi v pripade, ze je potreba uklidit neco jineho nez jen pamet.pochopitelne jsem, v kotextu tehle diskuze, myslel jen pamet (nakolik je dobre mit na uklid dalsich veci destruktor by byla asi jina diskuze)
Dnesni GC zadne objekty neodstranuji. Ony se mrtvymi objekty proste vubec nezabyvaji.to je jen slovickareni nebo jsem nepochopil, co jsi tim chtel rict
C++11 ma std::weak_ptrne ze bych delal v C++, ale diky, nevedel jsem, ze to tam taky existuje
free()
a neřeší objekty jednotlivě, jako v C++, kde se musí pořešit destruktory a podobně.
to je jen slovickareniChtel jsem tim rict, ze v tom je pristup destruktoru a GC zasadne odlisny. Destruktory se poctive zabyvaji kazdym mrtvym objektem. GC se zadnym mrtvym zabyvat nemusi. Proste slozitost v poctu mrtvych objektu je O(0). Ano, C++ se po 30 letech zacina stavat pouzitelnym jazykem
Slabe refence maji smysl, pokud chci odstrani objekt, na ktery ukazuji dalsi jine, stale zive, objektyJá jsem právě pochopil, že se tu řeší problém, kdy například handlery událostí drží reference na objekty, které by jinak mohl GC uklidit.
lze v C++ delat bud destruktorama coz je supr, nebo try/finallyC++ nemá finally.
ktorý robí v C++ menej než 5% časuMozna to je ten problem
Vlastne až moc vlastností. A to je tak trochu problém, lebo sa v tom už od C++0x nevyzná ani divá sviňa.Ano, neexistuje nekdo jako C++ expert. A temer vsechno je udelane tak na 90% a nic poradne, s plnem obskurnich pravidel.
Prakticky neobmedzený stack,Velikost stacku je zalezitost OS.
Na desktope tu zopár kandidátov je, ale chýbajú mi napr. bindingy pre Qt / QML.Vyvoj desktopovych aplikaci v C++ s vyjimkou specifickych veci jako je CAD ci herni frameworky je IMHO ekonomicky nerentabilni.
Ja bych ani nerekl ze c/c++ hodne ztratil, jenom proste neziskal nic navic
Jediná věc, která mi občas pomůže udělat si obrázek, jsou vlastní open source projekty.Potvrzuji. Já tedy nejsem na pozici, kdy bych mohl někoho přijímat, ale z mých zkušeností plyne, že právě opensource projekty (ve formě odkazu na github) mají posledních pár let v životopisu tu největší roli. Významnější než škola, než pracovní zkušenosti a set buzzwordů. Testovali jsme to před nějakou dobou s bývalým kolegou a když tam člověk dá odkaz na github profil s projekty, tak se mu šance na přijetí na místo programátora drasticky zvětšují.
netrpi tim ostatni zalibyMoje ostatní záliby kromě programování pro peníze jsou programování pro zábavu, čumění na filmy a čtení knížek. To se vybalancovat dá
osobni zivotTo se ale dá říct o libovolných jiných zálibách.
Moje ostatní záliby kromě programování pro peníze jsou programování pro zábavuPokud vam to prinasi miru radosti, ktera stoji za ten cas, pak je vse v poradku. Pokud vam to jako bonus pomuze v budoucnu na trhu prace, coz patrne ano, je to jeste lepsi.
To se ale dá říct o libovolných jiných zálibách.To jiste. Divil jsem se jen tomu, ze si programator po praci opet sedne k pocitaci a jako relaxaci zacne opet programovat.
Kvalitni a vytizeny programator ma chut pracovat ve volnem case na opensource?Když ponechám stranou, že to zda jsem kvalitní a vytížený programátor je silně diskutabilní, tak ano. Každý schopný programátor získal schopnosti převážně praxí (něco udělá i literatura a škola, ale ne zas tak moc). Praxe může být buďto komerční, nebo nekomerční. Komerční praxi většinou začátečníkům nikdo nezaplatí, a tak spousta lidí si píše své výtvory do šuplíku. Osobně pro to ale nevidím důvod, když je můžu nahodit na github, uvolnit pod komunitní licencí a potom použít jako referenci v životopise. Je to win-win situace, jak pro mě, tak pro komunitu, kde se teoreticky může najít někdo, komu se to bude hodit.
Chapu, ze pro nekoho to muze byt i konicek, ale netrpi tim ostatni zaliby a osobni zivot?To se špatně posuzuje. Asi jo, ale komu to má vadit, když ne mě? Je to prostě něco za něco.
Asi jo, ale komu to má vadit, když ne mě?Jiste, toto si musi rozhodnout kazdy sam. Pokud vam to vyhovuje, pak je vse v poradku. Ja jsem kdysi byl normalne zamestnan a k tomu jeste resil vlastni podnikani. Obe cinnosti byly placene, ale obe konzumovaly spoustu casu. Mou motivaci byl prijem, ktery mi umoznil zajistit investice, ktere mi umozni delat jen to, co mne bavi. Kazdy mame sve motivace pro sva konani.
Pravdou je, ze je perfektni, ze delate neco, co vas bavi a jeste to muzete pouzit na trhu prace.Přijde mi to skoro jako nutnost. Znám i lidi, které to bavit přestalo a většinou pak rychle vyhořeli a skončili někde v lese mimo lidi, kde žijí alternativně a třeba nechtějí dělat už nic jiného, než do konce života pěstovat včely na med.
Kvalitni a vytizeny programator ma chut pracovat ve volnem case na opensource?kdo rika, ze to musi byt ve volnem case? Nemala cast tech kvalitnich programatoru je placena za to, ze dela na open source.
Kvalitni a vytizeny programator ma chut pracovat ve volnem case na opensource?
Svobodný software neznamená „ve volném čase“ nebo „zadarmo“. Nicméně i když se budeme bavit o té části projektů, u které autor neplánuje přímou komercionalizaci, tak i tyhle věci beru jako součást profesního života a jako čas strávený v práci – do toho totiž počítám i celoživotní studium, bez kterého se programátor neobejde.
Výhoda svobodného softwaru a menších vlastních projektů je v tom, že jsi svým pánem a mj. si tam můžeš vyzkoušet nové technologie a postupy, na což v zaměstnání nebo u běžných zakázek není prostor – tam se hraje na jistotu, musí se stíhat termíny a použije se třeba i horší, ale ověřené řešení, pro které dokážeš dělat přesnější odhady a je větší šance, že se stihne všechno podle plánu. Jenže když budeš brát jen tyhle zakázky nebo budeš pořád zaměstnaný, tak se nic moc nového nenaučíš a budeš spíš zaostávat. A je lepší se učit na něčem, co sám potřebuješ, nebo to použije i někdo jiný, než si jen zkoušet učebnicové příklady.
Chapu, ze pro nekoho to muze byt i konicek, ale netrpi tim ostatni zaliby a osobni zivot?
Může trpět, ale to už je na každém, kolik chce trávit času v práci. Se svobodným softwarem to nesouvisí – jsou lidi, kteří žádný takový software nevytváří, dokonce ani nedělají nic užitečného a jejich práce je fakticky vzato na hovno, ale přesto tam tráví třeba 12 hodin denně a ještě si myslí, pro jak prestižní firmu dělají a jak je to super život.
Ukazovat to co udělal v předchozím zaměstnání bude těžko :)Není to nemožné, i když bych to jako zastánce open source neměl říkat. Já osobně jsem šel do open source firmy s kódem closed source projektů. Samozřejmě jsem si musel vyjednat souhlas s použitím vymezené části kódu k přijímacímu procesu a stejnětak jsem si dříve musel vyjednat souhlas se zněním reference v mém CV.
Ten souhlas jsi dostal nějak na papíře?E-mail se pokud vím považuje za písemnou formu. Navíc v těchto případech většinou potřebuješ mít znění toho svolení hlavně v případě, že dotyčný zapomene, co ti povolil, a tam snad obsah e-mailu nebude zpochybňovat a kdyby, tak ať si najde svoji verzi. Nedávali jsme tomu žádnou formu, jenom jsem je vždycky požádal, ať mi pošlou shrnutí toho, co jsme si domluvili do e-mailu, aby to mělo nějaké jasné znění.
A to s tím CV, k tomu snad souhlas nepotřebuješ, ne?Tak jako pokud máš podepsanou NDA na celý projekt, tak asi těžko můžeš jen tak do CV volně psát, na čem jsi dělal. A pokud nemáš, můžeš se dostat do problémů s obchodním tajemstvím nebo dalšími obecnými regulacemi.
Tak jako pokud máš podepsanou NDA na celý projekt, tak asi těžko můžeš jen tak do CV volně psát, na čem jsi dělal. A pokud nemáš, můžeš se dostat do problémů s obchodním tajemstvím nebo dalšími obecnými regulacemi.Já nevím jak moc toho do životopisu píšeš ty, ale já tam píšu jen od kdy do kdy, typ pozice (Python programátor třeba), jméno firmy a třeba krátký popis pozice, ve smyslu třeba Práce na backend komponentách systému Bla. Nějak se držím toho, že by se životopis měl vejít na dvě stránky a detaily stejně nikoho moc nezajímají.
že už pracovali ve 3 různých firmáchNo já to používám nikoliv jako kladnou, ale jako zápornou referenci. Lidi z určitých firem rovnou vyřadím (po mnoha zkušenostech a také na základě znalosti, jak to v daných firmách chodí).
Jediná věc, která mi občas pomůže udělat si obrázek, jsou vlastní open source projekty.Ano a pokaždé mě překvapí, kolik lidí v IT nemá ani vlastní web (i kdyby tam měli mít jen vizitku), ani nedokáže dát odkaz na nějaký svůj projekt.
Natoz pokud se jedna treba o C++ programatory.
V našem případě se jedná o lidi, kteří se nějakým způsobem budou zabývat tvorbou webových aplikací. Tam bych nějakou referenci na web očekával. Nejen očekával, hledám lidi, které to baví. Když je to baví, tak si jistě sobě, nebo svému klubu, nebo prostě jen tak nějaké stránky, určitě tvoří (asi by bylo zvláštní, kdyby se někdo nevěnoval své zálibě).
tak chces povedat ze namam sancu si najst pracuNic takového neříkám. Takových kluků k nám přišlo taky pár, pokecali jsme, vzali jsme si na sebe kontakty a domluvili jsme se na tom, že další spolupráce nedává smysl, protože se naše obory úplně míjejí. V některých případech jsme si i vzájemně poradili, koho přijmout / kam zajít se žádostí o zaměstnání. Pro obě strany výhodná schůzka (alespoň doufám, že pro obě). (Ano, není to klasický pohovor se žadatelem o zaměstnání, který bytostně nesnáším. Raději neformální pokec o životě, vesmíru a vůbec, z toho se dá poznat daleko víc, než z nějakého testu.)
nebo zda nebude kvuli kazdy drobnosti programovat rizeni jaderny elektrarnyUpřímně řečeno, jednou bych na takového chtěl narazit. Dneska je u mnohých lidí v módě "programování dle předpokladů: předpokládám, že tato situace nenastane, tak ji neošetřím". Pochopitelně v praxi dle Murphyho zákonů vždy nastane a rovnou v tu nejhorší chvíli. Člověka, který ošetří vše bez předpokladů, aby jeden pohledal.
On ten neformální pokec není ani o počasí ani o pečení bábovky. Je o tom, co ten člověk prožil v oboru zájmuHerr Gott, to jste pane Crhonek vystihl velmi presne. Soucasti me prace je i delat pohovory s uchazeci o praci. Ale nejedna se o IT obory. K pohovoru k IT pracovnikovi jsem byl parkrat prizvan jakozto poradni hlas, jelikoz mne nekteri kolegove povazuji za znaleho i v teto oblasti. Musim priznat, ze mne kdysi IT zivilo. Pracoval jsem jako programator uzavreneho software, ale to uz je vice nez deset let. Dnes bych si, bez radneho studia, na tu praci asi netroufl, i kdyz stale vidim v inzeratech, ze je celkem poptavka po bastleni v php, ansi c a jave, coz byl tehdy muj obor. A ano, petilete studium informatiky jsem absolvoval na jedne statni skole. Do dnesnich dnu se za to stydim, ale rikam si, ze ze svych dani jsem si sve studium jiz bohate zaplatil. Ale zpet k tematu. Dnes delam pohovory temer vyhradne na pozice, ktere souvisi s nizsim az strednim managementem, marketingem, a zejmena v posledni dobe HR. Absolventu soukromych skol, o kterych bych bezpecne vedel, ze odpovidaji pozadavkum, je u nas bohuzel zoufale malo. Obcas delam tyto pohovory i v Nemecku a Francii a musim rict, ze tam je situace mnohem lepsi a to hlavne v Nemecku. V Cechach je absolventu kvalitnich soukromych skol malo, takze se dany uchaze musi proverit z jinych uhlu pohledu. A zde prichazi na radu ten "neformalni pokec".. Tedy ne, ze bychom podobny "pokec" neprovedli i u zjevne kvalitniho uchazece, ale je mu u nej prikladan ponekud mensi duraz. Prijde mi, ze vystup z daneho pokecu u daneho cloveka ma kolikrat vetsi hodnotu nez seznam titulu, ktere vam dany clovek dokaze diplomem. Clovek zjisti, jake ma uchazec nazory, co prozil, kde byl, jak umi jazyky, co za relevantni literaturu precetl, jake ma volnocasove aktivity, jak je na tom se vztahy, jake lidi a jak casto potkava, jak bydli, atd. Toto vam o cloveku rekne strasne moc. Nemam problem prijmout stredoskolaka na pomerne financne zajimavou pozici, kdyz vidim, ze ma o svuj obor zajem a ze o svem oboru vi kolikrat vice nez uchazeci, kteri sice maji onen statni bc titul, ale pri tom o svem oboru v zivote nic neprecetli a krome naucenych statnich skript nedisponuji relevantnimi znalostmi. Typickym prikladem tohoto neblaheho stavu jsou absolventi ekonomickych fakult na statnich skolach. Prijde mi, ze pokud dospivajici adolescenti nevi, kam by sli, tak si daji prihlasku na "ekonomku", a pak cekaji, ze sezenou velmi dobre placenou praci.
A ano, petilete studium informatiky jsem absolvoval na jedne statni skole.Nekdo ti hacknul ucet! Ja jsem zadarmo opravdu nestudoval, toho se nebojte.
Ten troll si už ani nepamatuje, co napsal.Neni to troll a pamet mu slouzi, neboj.
V jeho věku logicky musel absolvovat státní školství, možná i volit bolševika.O tom vzdelani zde toho padlo jiz dost. Netajil jsem se s tim nikdy. Tezko nekomu toto vycitat, kdyz nemel jinou moznost volby diky statem nastavenym podminkam. I dnes, kdy maji studenti moznost volby, nekritizuji samotne studenty za studium na statnich skolach. Kritizuji politiky, kteri existenci tohoto ostudneho prerozdelovaciho stavu dovoluji a nedej buh podporuji.
Bojuje proti rozbujelé státní administrativně pouze kecama na ábíčkuNeznas mne, takze toto nemuzes tvrdit.
Přičemž firma, která ho živí, hrabe hlavně ze státního sektoru.Opet dalsi lez.
Takového klenota může na pohovory s novými zaměstnanci najmout jen skutečně zoufalá instituce.Nevim, jestli je zoufala. Podle mne je docela v kondici.
vlastny web nepotrebujem a fakt nemam cas tvorit takyto web a ani netusim co tam dat, stranky zvladam robit, ale ked som ich robil vo firme kde dane stranky boli len pre interny obchodny systemTo je jak smíření a jsi skoro tam. V bodech:
Kdyz uz byla rec o C++, tak se obavam, ze brzy budeme muset snizit latku, protoze na trhu dobrych lidi opravdu moc neni
Kolik toho z C++ využíváte? Jak dlouho by to trvalo naučit dobrého programátora, který zatím dělal jen v jiných jazycích?
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.