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.

Zahoďte knihovny: dropdowny, tooltipy a přechody stránek jen s HTML a CSS

Rozbalovací menu, tooltip, modální okno a plynulý přechod mezi stránkami. Ještě nedávno čtyři důvody, proč do projektu přidat několik knihoven a desítky kilobajtů JavaScriptu. V roce 2026 už to všechno zvládne prohlížeč sám. Ukážeme si, jak na to s Popover API, CSS anchor positioningem a View Transitions, a také kde mají své limity.

Rok po Shai-Hulud: co se změnilo na npm a co musíte udělat do ledna

Před rokem začal registrem npm procházet samošířící červ Shai-Hulud. Od té doby se útoky na dodavatelský řetězec JavaScriptu staly pravidelnou záležitostí a npm postupně přepisuje pravidla publikování. Projdeme, co se za ten rok stalo, jak dnes bezpečně publikovat balíček, co musíte stihnout do ledna 2027 a jak se bránit jako uživatel balíčků.

Vercel zrychlil směrování v CDN. Překvapivě pomohly menší bloky

Vercel zrychlil směrování v CDN tím, že začal načítat víc dat najednou. U velkých webů mu po každém nasazení scházely v cache údaje o mnoha jednotlivých cestách, takže je musel opakovaně dohledávat. U nových bloků metadat Vercel naměřil o 91 % kratší dobu tohoto hledání v 99. percentilu. Cesta k výsledku ale vedla přes nečekané zjištění: příliš velký blok se při vyřizování požadavků nevyplatil.