Přejít k navigační liště

Zdroják » Zprávičky » Čtyři pravidla režimu „Pište kód každý den“

Čtyři pravidla režimu „Pište kód každý den“

Zprávičky Různé

John Resig (autor jQuery) ve svém článku představuje pravidla pro Write Code Every Day. Johnovým problémem byla řada menších open source projektů, kterým se věnoval ve svém volném čase. To bylo zpravidla o víkendech a výsledek Johna neuspokojoval.

Stanovil si proto následující pravidla:

  1. Budu psát kód každý den. Můžu psát dokumentaci, můžu blogovat nebo psát něco jiného, ale to vše až když napíšu nějaký kód.
  2. Musí se jednat o užitečný kód. Nebude to jen úprava odsazení nebo refaktoring. (To samozřejmě není zakázáno, ale nepočítá se do to každodenního kódu.)
  3. Všechen kód musí být napsán do půlnoci.
  4. Musí se jednat o open source dostupný na GitHubu.

Johnovi se podařilo plnit tato pravidla téměř 20 týdnů a znamenala lepší pokrok v práci na jeho projektech. Jonh vše detailně rozebírá ve svém článku, nejen že udělal mnohem víc práce, ale při té pravidelné činnosti se mu dařilo držet podstatné věci v hlavě a napadaly ho zajímavé věci třeba při procházce nebo ve sprše.

Zkusil někdo z vás něco podobného? Jaké máte zkušenosti?

Komentáře

Odebírat
Upozornit na
guest
4 Komentářů
Nejstarší
Nejnovější Nejvíce hlasů
fczbkk

Existujú projekty pre spisovateľov (napr. 750 Words, NaNoWriMo a pod.), ktoré majú za cieľ motivovať ľudí k pravidelnému písaniu textov. Možno by pomohlo, keby existovali podobné projekty aj pre kóderov. Zverejňovali by ich progress, dávali by im achievementy, atď. Neviem, či už niečo také existuje. Ale ak nie, nad GitHub API by to iste šlo celkom ľahko postaviť. Open source komunita by z toho iste profitovala.

Petr

a vydrzel 41 dnu. Po X hodinach programovani v praci jsem doma uz nebyl schopen udelat nic extra velkeho. Nektere dny byl jeden commit s nejakou banalni opravou. Obvykle o vikendech bylo commitu vice a i rozsahlejsi veci. Kdybych to po tech 41 dnech tlacil dale, asi bych casem stejne odpadl a trvalo by tak mesic nebo dva nez bych byl schopen programovat i neco doma.

Češtin

Věci ho napadal*y*.

Grumpa

Nastavit si minimum denní práce může opravdu brzy skončit utavením. Já se to snažím dělat opačně: Než se do něčeho pustím, ptám se kolik času a energie tomu můžu věnovat dlouhodobě nebo ještě lépe trvale.
Byl jsem u projektů, které začaly velkým nadšením a pak rychle skončily. Teď si to nadšení samozřejmě taky rád užiju, ale často ho nechám vyšumět a jdu se věnovat něčemu, na čem už delší dobu pracuji.
Ono není nic špatného zjistit, že moje místo v tomto vesmíru je u nějaké menší utilitky, která ale funguje a lidi jí rádi používají.
Taky se rád pouštím do nových věcí, ale ty již fungující by tím neměly trpět.

Proč vám model napíše Python, i když jste si řekli o Rust

AI
Komentáře: 0
Výkonnostní propast mezi Pythonem a ostatními jazyky se za poslední rok a půl skoro zavřela. Dnešní modely zvládají Rust i Go srovnatelně dobře. Když jim ale volbu necháte, sáhnou stejně po Pythonu. A u knihoven je to ještě výraznější: mezi funkčně srovnatelnými balíčky je až 84procentní rozdíl v kvalitě generovaného kódu. Proč to tak je a co s tím.

WP2Shell: Kritická hrozba pro samotné jádro WordPressu. Útočníci mohou získat kontrolu nad webem

Zranitelnost ve WordPressu není žádná novinka. Kdo provozuje weby postavené na této platformě, ví, že bezpečnostní záplaty chodí prakticky pořád. O to větší pozornost by měla vzbudit chyba, u které nic z toho neplatí. A přesně takový je případ zranitelnosti, která dostala přezdívku wp2shell. potřeb. Zranitelný kontaktní formulář, děravý e-shopový plugin, opomenutá kontrola oprávnění v nějaké obskurní rozšiřující knihovně – to je denní chleba každého, kdo sleduje bezpečnostní feedy. Zpráva „nová chyba ve WordPress pluginu“ má tak nízkou informační hodnotu, že ji většina lidí přejde bez mrknutí oka.

Mýtus jedné aplikace: proč PWA nenahradí vývoj pro každou platformu

PWA mohou webu přidat ikonu na ploše, fungování bez připojení, notifikace a některé systémové funkce. Nejsou ale cestou k jednomu klientu pro všechny platformy. Vyplatí se tam, kde se lidé k webu vracejí a ocení okamžitý vstup z odkazu. Jakmile aplikace musí spolehlivě běžet na pozadí nebo fungovat stejně na každém zařízení, bývá vhodnější nativní řešení.