Kde na webu nalézt JS knihovny?

Někdy není potřeba knihovnu stahovat, stačí ji nalinkovat. Hledáte vhodnou CDN?

  • jsDelivr: CDNky pro JS knihovny, jQuery pluginy, fonty a další
  • cdnjs: CDN hosting pro méně známé knihovny

Vzdálené úložiště pro webovou aplikaci

Řeším takový problém u svého online assembleru – totiž jak ukládat vzdáleně soubory…

Continue Reading

API je nové open source

Otevřte svůj software světu… Však kvůli tomu nemusíte hned vystavovat zdroják na web a vypínat firewall!

K open source jsou dva různé přístupy. Jeden přístup neideologický a pragmatický („BSD-like“), a druhý podložený ideologií („GNU style“). V tom prvním přistupujete k tvorbě open source jako k věci osobní volby: tenhle kód by se mohl někomu hodit, tak ať ho můžou lidi používat, je mi jedno, co s tím budou dělat, když jim to k něčemu bude, ať to spánembohem používají. Druhý přístup vychází z přesvědčení, že „software by měl být otevřený“, a tak se snažíte, aby váš kód byl otevřený, aby byl otevřený kód těch, co přijdou po vás, aby i další museli otevřít svůj kód, pokud chtějí používat ten váš… Rozdíl mezi těmito přístupy je fundamentální, a tak nelze říct, který z nich je lepší. Vždycky budete hodnotit podle svých osobních preferencí a sympatií.

Trochu mi to připomíná postoje, řekněme, k životnímu prostředí. Někdo prostě třídí odpad, protože mu to připadá přirozené – plasty do jednoho koše, papír do druhého, jaképak s tím ciráty. No a někdo bere třídění odpadu jako věc, kterou je nutno evangelizovat a šířit všude, včetně vymýšlení samolepek s lebkou a nápisem „jsem lůzr a zabíjím planetu, protože netřídím odpad“.

Ideologická zaťatost může spustit hnutí dobrým směrem, ale po čase, když se stanou některé její myšlenky součástí obecně přijímaného pohledu na věc, začne být ideologická rigidita k smíchu.

Takhle nějak  se stalo open source samozřejmostí mezi pragmatiky. Píšu nějakou větší věc a v jejím rámci vznikne pár menších knihoven. Tak je napíšu obecně, hodím na GitHub a dám je jako open source, aniž bych od toho něco čekal, ale zároveň ta větší věc zůstane zavřená, pokud ji zavřenou chci. Obrovskou roli v takovémhle myšlenkovém posunu hrály tři věci: GitHub, JavaScript a API.

GitHub tím, že publikovat knihovnu, sdílet ji, upravit ji a navrhnout úpravy zpět autorovi je velmi snadné. Navíc je ten postup jednotný a nezávislý na konkrétním autorovi. Nemusíte hledat, jestli tomuhle pánovi psát mail, navrhovat mu to ve wiki, ve fóru… prostě vytvoříte pull request, vysvětlíte, co vaše úprava řeší a proč by měla být přijata, a hotovo.

JavaScript napomohl otevření velkého množství knihoven pod velmi volnými licencemi tím, že zatím nemáme jeho binární ekvivalent. Zatím servery posílají kód v otevřené zdrojové podobě (minifikace není zas taková překážka), a tak se webaři taknějak smířili s tím, že jejich kód je otevřený, a od smíření k akceptaci je jen krůček.

Konečně API je myšlenková konstrukce, která rozvolnila ostrou hranici mezi „open source“ a „closed source“ a umožnila sblížení obou táborů na pragmatickém základu: „Closed source, ale to nevadí“.

Do masivního nástupu API se taknějak věřilo, a evangelizátoři open source na tom stavěli, že otevřený software znamená automaticky demokratický software (a „demokratický“ je „lepší“, kdo řekne že ne, ten je fuj), u kterého se na vývoji může podílet každý, a to je dobré. „Otevřený software,“ hlásali, „má víc a lepších funkcí, právě proto, že si do něj může každý dopsat co potřebuje! To u closed source nejde!“ API ten poslední argument odstřelilo. Díky API můžete closed source software rozšířit o užitečné funkce, aniž byste se vrtali v něčích zdrojácích. Facebook, Google, Twitter a asi tuna dalších služeb a software je „closed source“, ale právě díky API to moc nevadí. API je vlastně nejlevnější způsob najímání vývojářů – nemusíte je zaměstnávat, a oni i přesto rozšiřují funkce vašeho software. Koexistence „fujkomerce“ a „sluníčkové svobody“ je najednou realitou.

Není to vždycky stoprocentní, mnozí poskytovatelé API na „své“ vývojáře kašlou a mění jim API pod rukama, ale situace je pořád lepší než před lety, kdy by východiskem z takové situace byl jeden closed source projekt a šest pokusů napsat jeho open source alternativu, protože „s nima se nebavíme“ (z obou stran bariéry). Jasně, i dneska budou ideologičtí horlivci, co odmítnou jakoukoli spolupráci s „komercí“ („Nebudu pro ně zdarma vyvíjet, aby na tom oni rejžovali!“) či s nezávislými vývojáři („Nebudeme jim zdarma poskytovat naše drahé knowhow a strojový čas, vždyť bychom tím posilovali konkurenci“*), ale pro pragmatiky to je vítaná možnost, jak se nezabývat ideologickými překážkami a těžit z obou světů to nejlepší.

Jo, opravdu věřím tomu, že API je způsob, jak skloubit výhody closed source a open source, a že bychom se měli naučit s API víc pracovat – nejen je využívat, ale taky je poskytovat. A věřím v to (a hlásám to) už asi pět let…

Oprava pluginu pro Sublime Text 2

Sublime Text 2 je výtečný textový editor pro vývojáře. Je skvělé, že k němu máme tuny pluginů; horší je, když plugin nefunguje a hlásí mysteriózní chybu [Decode error – output not utf-8]. Čím to je a co s tím?

Na tenhle problém jsem narazil asi u tří pluginů (používám Sublime pro Windows, pro pořádek, ve vašich systémech to může mít příčinu jinou). U dvou jsem to neřešil, ale u toho třetího (LiveScript) už mi to nedalo. Když googlíte, najdete poměrně užitečnou radu, totiž že máte někam napsat kódování, které bude jiné než UTF-8. Hmmm…

Stáhnul jsem plugin LiveScript, napsal skript v LiveScriptu, uložil ho jako soubor s příponou .ls a stisknul F7. Objevil se chybový výpis, kterému vévodila výše uvedená chyba s utf-8. Co teď?

Nejprve je třeba zjistit, v jakém kódování váš systém funguje. Spusťte si příkazový řádek a zadejte „chcp“. Vypíše vám aktivní stránku. Mně vypsal „852“. (Takže ne 1250, jak jsem tipoval…)

Najděte si sublime-build soubor u daného modulu. Já ho našel v packages/LiveScript/Commands/CoffeeScript.sublime-build (ano, CoffeeScript, není to překlep). Na poslední řádek s parametryjsem doplnil:

a spustil znovu (F7). Chyba se změnila! Teď jsem se dozvěděl: [Error 2] Syst*m nb7pf uvedenž-čš* ubor.

Aha! „File not found“, napsaný česky, v prapodivném kódování a nesmyslně zkonvertovaný! Skvělé, že to vím – ale jaký soubor nebyl nalezen?

Koukám do toho sublime-build a dumám… Je tam toto:

To kódování jsem tam dopisoval já. Co tam máme dál? Tak, šachuje se s path podle zvyklostí na *nixu, to by asibylo dobré vyhodit. Pryč s tím! Vyhodil jsem, a výsledek stále stejný. Divné – spouští se příkaz „livescript“, je v cestě, z příkazového řádku funguje bez problémů… Mnojo. Jenže Sublime nepouští příkazový řádek, který najde vhodný soubor s příponou .exe, .com, .bat, .cmd, ale volá ho rovnou! Koukám se do adresáře npm a vidím, že mám k dispozici „livescript“ a „livescript.cmd“. Takže doplním do sublime-build to „.cmd“ – a výsledek? Funguje to!

Výsledný .sublime-build, který funguje na Windows, je tedy:

Třeba vám ten postup někdy k něčemu bude.

banner

Copyright © 2017. Powered by WordPress & Romangie Theme.

banner