Planeta.OpenAlt.org

Proč pro mě Angular není správná volba

listopad
20
Milan Lempera

V minulosti jsem se hodně věnoval JS, AngularJS a společně s Víťou Plškem vybudoval angular.cz. Dělali jsme školení, konzultace, workshopy a přednášky o tomto frameworku a JavaScriptu obecně. Byla to aktivita, která mě bavila a pár let živila. Pak přišlo oznámení nové verze frameworku (Angular 2), který se zdál jako ideální pokračování téhle cesty. 


Angular 2 jsme školili asi rok a za tu dobu jsem si ujasnil, že je to technologie, která mi nesedí. Ze školení jsem se stáhnul a více se zaměřil na vývoj (převážně v Reactu s občasnými experimenty s Clojure/Scriptem).

Nyní asi po 2 letech jsem měl možnost vidět větší Angular projekty a konzultovat problémy okolo best practices v tomto frameworku. To mi dalo možnost vrátit se k původním úvahám a potvrdit si, že Angular opravdu není pro mě. V několika bodech zkusím vysvětlit proč.





TLDR: článek je opravdu dlouhý a vyžaduje alespoň základní znalost frameworku. Pokud se nechcete trápit s detaily, projeďte nadpisy a mrkněte rovnou na závěr ;-).

TypeScript

Mám rád JS, mám rád dynamické jazyky a v TS jsem dlouhou dobu viděl spíše komplikaci než přínos.
Snaží se svázat dynamický JS svět do statických typů, což jde dobře u věcí jako jsou třídy nebo pevně dané objekty. Typování dynamických věcí (třeba Ramda funkcí) je něco příšerného.
Navíc TS své dynamické schopnosti nabýval až postupně, takže dnes je dál, ale i tak je to poměrně zvláštní jazyk. Java/C# programátoři v něm vidí své jazyky a jsou z něj nadšení, do doby než zjistí, že všechno je jinak. Třeba, že:

  • typy jsou strukturální 
  • chovají se různě dle kontextu 
Milovníci Haskelu nebo Scaly si jej možná oblíbí, protože vám dovolí otypovat ledacos. To ale neznamená, že se v tom pak někdo další vyzná.

Nejdůležitější je uvědomit si, že TS není jen JS s typy. Je to prostě samostatný jazyk s vlastní syntaxí a klíčovými slovy. I když jeho velkou část znáte, protože se potkává s JS, vyplatí se věnovat nějaký čas studiu specifických vlastností TS. Předejte tím překvapením nad kódem.

Výhodou může být, že konfigurací si TS můžete ohnout z neškodné hračky na statický typový bič, který vám neodpustí vůbec nic. Záleží tedy, jak moc na sebe budete přísní.

TypeScript je primární jazyk Angularu. Framework vám dodává konfiguraci, která není moc striktní, což je pro začátek prima, ale na druhou stranu taky není moc typově bezpečná. Zapomeňte třeba na strict null checks.

Ani kód Angularu si s nějakým silným typováním příliš hlavu neláme, spočítejte si cvičně výskyty any ve zdrojácích frameworku (https://github.com/angular/angular/search?l=TypeScript&q=any) Na obhajobu Angularu je potřeba uvést, že v době jeho vzniku nebyl ještě TS zdaleka tak silný v popisu dynamických konstrukcí, jako je dnes.

Integrace s RxJS

RxJS je technologie, která mě baví. Angular ji podporuje a interně ji používá (EventEmmiter je vlastně Rx Subject). Bohužel způsob použití a edukace programátorů je řekněme “nešťastný”.


Nováčci v Angularu jsou zmatení a netuší, proč si nevystačí se starým dobrým Promise. Proč je najednou ajax request Observable?


Nakonec nějak přechroupou tutoriálové použití http (https://angular.io/tutorial/toh-pt6), kde se bohužel nedozvědí moc o tom, že http je speciální případ observable s jednou hodnotou, který je následně ukončen. Ani o tom, že u ostatních Observable, pokud zavoláte subscribe(), měli byste zavolat taky unsubscribe(). 


Samozřejmě, máme async pipe, kterou je dobré použít, ale jsou situace kdy se to úplně nehodí. A pak volíte menší zlo - v každé komponentě doplňujete pořád dokola ngDestroy, ve kterém se buď unsubscribujete, nebo všude cpete takeUntil (https://blog.codecentric.de/en/2018/01/different-ways-unsubscribing-rxjs-observables-angular/).

Když vidíte tolik duplicity, určitě vás napadne, že by to mělo mít nějaké elegantní řešení. Různé knihovny se to snaží řešit více čí méně magicky.

Bohužel, všechny s sebou přináší něco jako

// because of aot we need to implement the ngOnDestroy method for @Destroy to work
ngOnDestroy(): void {}


Ok, smíříte se s tím, budete všude psát subscribe() a unsubscribe(), jenže jednoho krásného dne narazíte na ChangeDetectionStrategy.OnPush.


A k subscribe přibude ještě injektování ChangeDetectorRef a volání markForCheck().


To oboje by za vás vyřešila async pipe, to ale většinou vede k rozpadu na 2 komponenty - chytrou a hloupou.  Chytrá získá Observable a s pomocí async pipe jeho hodnoty posílá do hloupé komponenty.


To řešení je docela dobré, jen přináší režii tvorby komponenty navíc, což je při živějším vývoji věc, kterou můžete psát (generovat) a mazat poměrně často.


Od verze 4 můžete použít ještě async pipe v kombinaci s ngIf-as, tedy něco jako


*ngIf="observable | async as data; else loading" 


Použití tohoto konstruktu je alternativou ke tvorbě chytré a hloupé komponenty. Některá použití jsou ale vlastně zneužití ngIf k přiřazení do lokální proměnné, protože podmínka jako taková je vždy splněna.


Angular vám přináší RxJS, ale už vám neříká, jak ho správně používat ve složitějších use-casech. Chybí podpora pro unsubscribe v komponentě, takže pokud si nevystačíte s http a async pipe, bude správa subscription v komponentách tvořit nezanedbatelnou část opakujícího se kódu. (To, že RxJS je funkcionální a s OOP a prací s this v JS taky nejde úplně hladce dohromady - místo metod musíte psát vlastnosti s bindovaným this - raději pomiňme).

Change detection

Když budete psát aplikaci (nebo framework), pro detekci změn si můžete vybrat v zásadě ze dvou způsobů - buď vystavíte explicitní API pro změnu stavu (něco jako https://reactjs.org/docs/react-component.html#setstate) nebo vymyslíte nějakou magii, kde programátor prostě zapisuje do vlastností a změny se propagují. 


Angular si vybral druhou cestu. Je fér říci, že “magie” je teď v kurzu, používá ji také Vue a Svelve. Oproti Angular.js na to jde Angular lépe a s daleko menší režií. Používá Zone.js (https://github.com/angular/angular/tree/master/packages/zone.js/) a zajistí si, aby o všem, co se děje (třeba i asynchronně), věděl. Kvůli tomu vám přepíše všechny globální funkce (jako setTimeout, setInterval,…) což IMHO trochu smrdí, ale berme to jako daň za to, že se nemusíte o nic starat. 


Pokud nejste příliš šťouravý vývojář, začnete svou aplikaci vyvíjet a až když vám přijde pomalá, nebo až se budete divit, že některé věci se volají zbytečně často, dogooglíte se k ChangeDetectionStrategy.OnPush. Začnete ji používat, čímž narazíte na výše zmíněné markForCheck - tedy potřebu programově notifikovat Angular, že došlo ke změně (explicitní API pro změnu stavu, ovšem pouze pro specifické případy?).


Takže i přes enormní snahu a patchování globálních funkcí nás Angular od této problematiky úplně neodstínil.

Do zón se nakonec budete muset ponořit i kvůli optimalizaci výkonu (resp. zbytečného spouštění checking) - viz https://blog.thoughtram.io/angular/2017/02/21/using-zones-in-angular-for-better-performance.html

Když se na to podívám s odstupem, přijde mi tahle abstrakce poněkud děravá.

Formuláře

Jedna z vlastností Angular.js, které jsem měl opravdu rád, byly formuláře. Jejich model stavových informací formuláře a prvků se opravdu dobře používal, byl jednoduchý a nevyžadoval přitom psát moc kódu.


Angular se ho snaží dodržet, ale sám neví kudy na to, tak vám nabízí rovnou api dvě - šablonové a reaktivní formuláře. 


Stručně řečeno - šablonové formuláře si odvozují objektovou strukturu z šablony, u reaktivních definujete objektovou strukturu sami v kódu, a pak ji navážete na šablonu. Ani pojmenování není nejšťastnější. Lepší by asi bylo template based vs code defined, protože reaktivní API je v obou variantách.


Obvyklý postup méně zkušených je ten, že začnete šablonovou verzí, protože máte přece jednoduchý formulář. On vám ale brzy přeroste do vlastností, které chcete spíše řídit v kódu, a tak to všechno pěkně přepíšete do reaktivní varianty. 


Ani jedna z variant formulářů nepřináší oproti Angular.js žádné velké výhody, jen vyžaduje napsání více kódu.


Formuláře jsou mimochodem dobrou ukázkou toho, jak vážně to Angular myslí s TS. 


Formulář je řízený daty, tedy nějakým modelem. Čekali bychom tedy obecný generický typ T, jako třeba

type FormDefinition<T> = {
    [key in keyof T]: FormDefinitionItem;
};


v kódu Angularu, a pak snadné použití

interface Model {
    title: number
    content: string
    otherField?: boolean
}


a

const formDefinition : FormDefinition<Model> = {
    title: [''],
    content: ['']
};


this.form = this.formBuilder.group(formDefinition);


Tak takhle přesně to nefunguje. Vzpomínáte, jak jsme počítali any ve zdrojáku? Tak zrovna tady https://github.com/angular/angular/blob/master/packages/forms/src/form_builder.ts?#L57 je další výskyt. 


Takže na nějakou typovou chytristiku zapomeňte nebo si ji napište sami.


Objektově řízené formuláře se obecně zdají jako dobrá myšlenka, bohužel ale v Angularu dost nedotažená nejen po stránce typů - všimli jste si varování v této sekci


Caution: Use HTML5 validation attributes in combination with the built-in validators provided by Angular's reactive forms. Using these in combination prevents errors when the expression is changed after the template has been checked.

Jako že u formuláře, který definuji v kódu, bych měl duplicitně dopisovat vlastnost required do HTML???

Jak komplikovaná může být práce se složitějšími formuláři, je vidět na množství kódu, který musíte napsat, chcete-li jeden formulář rozdělit do několika komponent https://blog.angularindepth.com/angular-nested-reactive-forms-using-cvas-b394ba2e5d0d,
 nebo na příkladu práce s disabled https://netbasal.com/disabling-form-controls-when-working-with-reactive-forms-in-angular-549dd7b42110

DI

Zatímco Angular.js měl globální DI kontejner, Angular na to jde sofistikovaněji - má hierarchické DI (https://angular.io/guide/hierarchical-dependency-injection), což zní jako skvělý nápad. Umožňuje vám podrobné nastavení a různá (magická) kouzla. 


Koneckonců DI zná každý OOP programátor, takže tam nemůže být žádný problém, ne?


Pokud komponenta potřebuje nějakou službu, dohledává se od jejího umístění ve stromu komponent směrem nahoru. Použije se nejbližší nadřazený provider. Tady je vše elegantní a srozumitelné.


Komponenty jsou pouze jedno z míst, kde můžete providovat služby. Dalším místem je modul. Služba providovaná v modulu je ale globální - tedy chová se stejně jako služby v AngularJS. To je při důrazu na modulární systém docela nepříjemné a může to vést ke skrytým závislostem, protože není nic,co by vás nutilo definovat závislost na modulu, při použití jím providované služby. 


Tedy služby providované v modulu se chovají stejně jako v AngularJS, kde bylo právě nevyjádření závislosti velkou komplikací při údržbě a refactoringu větší aplikace.

Aby toho nebylo málo, pro lazy načítané moduly toto neplatí (viz. https://angular.io/guide/providers#limiting-provider-scope-by-lazy-loading-modules). Pokud v existující aplikaci zavedete lazy-loading některých modulů, může dojít ke změně chování nebo nefunkčnosti celé aplikace - další děravá abstrakce?

Šablona, mikrosyntaxe

V Angularu píšete šablony v HTML doplněném o Angular speciality a vámi vytvořené komponenty. Je to v podstatě stejné jako v Angular.js (podobné jako ve Vue,…), jen narazíte na některé podivnosti (BANANA IN A BOX jistě znáte).


S tím se dá žít, ale z principu HTML šablon plynou dvě věci:

  • Protože šablony nejsou jen převlečený JS kód (narozdíl od JSX), nemůžete vy ani vaše IDE využívat JS tooling.
  • Použité komponenty nemůžete přímo importovat, protože prostě nejste v JS, ale v HTML. To znamená, že komponenty, které chcete v šabloně použít, musíte naimportovat přes modul - tedy ve svém modulu naimportovat modul, kde jsou komponenty definované. Modul definujeme v jiném souboru, takže vazba mezi použitím v šabloně a konkrétní komponentou je, řekněme, hůře zřetelná. Většinou ji neuvidíte ani v ukázkách použití knihoven (https://material.angular.io/components/form-field/examples). U těch lépe dokumentovaných je alespoň v popisu API. 
  • nemůžete snadno zjistit, které komponenty jsou importované, ale nejsou použité - struktura skutečně není snadno zřetelná, což může překážet při refaktoringu, rozdělování modulů nebo rozplétání cyklických závislostí. 
  • kompilace šablony musí mít celý kontext - strom závislostí, moduly atd., takže může být opravdu pomalá, což se zpravidla projeví až při vývoji větší aplikace. Viděl jsem středně velké aplikace, kde čekáte 40 sekund na livereload. Abych byl spravedlivý, lazy loading to do jisté míry řeší. Na časy transpilace JSX se nedostanete už z principu právě kvůli závislosti šablony na kontextu modulu.
      Použití HTML šablony můžete vidět jako výhodu (třeba jako Viktor Savkin https://blog.angularjs.org/2016/03/why-angular-renders-components-with.html), ale v reálu narazíte na limity. Některé vlastnosti se v html zapisují blbě. Bylo by hezčí, kdybychom v šabloně mohli použít kód.

      <li *ngFor="let item of items; index as i; trackBy: trackByFn">...</li>
      Nezkušený angularista by mohl nabýt dojmu, že jde o JS, ale jde o dojem falešný. Ve skutečnosti je to jen syntax sugar pro

      <ng-template ngFor let-item [ngForOf]="items" let-i="index" [ngForTrackBy]="trackByFn">


      Obecně strukturální directivy (ty označené hvězdičkou) a jejich implementace jsou místem, kde vidím nadměrnou komplexitu jako projev špatně zvolené abstrakce.


      Další “zvláštností” kombinace HTML šablony a způsobu, jakým Angular šíří a zpracovává události, je, že Output může být volán parazitně bublající DOM událostí. Dokumentace vás na to neupozorní.Style guide o pojmenování to nezmiňuje a mně občas přiskočí body za dotaz na Stack Overflow. Bohužel, řešení to nemá. Resp. buď se to riziko ignoruje, nebo se události prefixují on-, což nedoporučuje styleguide
      Další možná obezlička je prefixovat názvy událostí komponenty, což zní na první pohled rozumně, ale úplně to zabijí nahraditelnost komponent. I když mají dvě komponenty vlastně stejné API, jejich Output vlastnosti jsou pojmenované odlišně. Je to stejné, jako kdybyste public metody nějaké třídy prefixovali názvem třídy. Prostě antipattern.


      Chybám v názvech událostí můžete předejít i analýzou kódu https://github.com/mgechev/codelyzer/pull/474. Workarounds tedy jsou, ale čisté řešení mezi nimi nevidím. Čekal bych, že se k tomuto problému autoři frameworku postaví lépe.


      V odkazovaném článku V. Savkina je hodně vyzdvihována statičnost šablon jako výhoda. Druhá strana mince je ale složitost dynamického použití komponenty.
      V JSX můžete komponentu předat přes proměnnou a je jedno, jestli jste ji získali jako výsledek ternárního operátoru nebo třeba z dynamické mapy komponent.

      function DynamicRenderer () {
          const Component = this.props.condition ? SomeComponent : SomeOtherComponent;
          return <Component />
      }


      V Angular šabloně jste odkázaní na if/switch v případě méně dynamické varianty, nebo hrátky s viewContainerem, pokud to s dynamikou myslíte vážně. https://netbasal.com/dynamically-creating-components-with-angular-a7346f4a982d


      Případně můžete použít https://angular.io/api/common/NgComponentOutlet, kde lze dynamicky vybrat komponentu. Závislosti jí ale musíte předat přes Injector, takže pokud jste namlsaní ze snadných manipulací s “props” v Reactu, tohle řešení vám bude nejspíš připadat neohrabané.

      V souvislosti se šablonami můžete ještě narazit na dekorátory @HostListener, @HostBinding nebo na vlastnost https://angular.io/api/core/Directive#host u directivy/komponenty. Ty ukazují, že myšlenka deklarativní oddělené šablony v HTML může vypadat lákavě, ale není možné ji jako jednotný koncept udržet napříč frameworkem. Directivy potřebují způsob jak modifikovat vlastnosti elementu, na kterém jsou použité. Stejně tak v komponentě nemáte host element uveden v šabloně, takže deklarativní definice vlastností a událostí nemůžete využít.

      Moduly

      NgModule v současné podobě přišel do Angularu až v RC5 Do té doby se “závislosti” psaly u komponent - např. něco jako

      @Component({
          selector: 'my-component',
          styles: [`
              h1 {
                  font-size: 200px
              }
          `]
          template: `
              <h1>Hello from MyComponent.</h1>
               <my-other-component></my-other-component>`,
          providers: [MyProvider], // MyProvider is a fictional service
          directives: [MyOtherComponent] // MyOtherDirective is a fictional component
      })
      export class MyComponent {}


      Bylo to sice ukecané, ale díky tomu byla komponenta atomická. V RC5 se závislosti přesunuly do modulu, což jistě snížilo množství kódu, ale cenou je ztráta atomicity komponenty

      @NgModule({
          imports: [ BrowserModule ],
          declarations: [ AppComponent ],
          bootstrap: [ AppComponent ]
      })
      export class AppModule { }


      (kód jsem si půjčil z https://auth0.com/blog/angular-2-ngmodules/)

      Komponenta nebo directiva použitá v šabloně musí být definována v modulu. To může vést ke dvěma problémům:
      • použití stejného kódu (zkopírované) komponenty na jiném místě nemusí fungovat nebo může fungovat jinak, pokud se potkají názvy directiv/komponent 
      • použití samostatné komponenty izolovaně při vývoji je problematické. Např. ve Storybooku často duplikujete definici závislostí, což značně snižuje lákavost jeho použití. To je velká škoda, protože vývoj izolovaných komponent mimo aplikaci je skvělé zrychlení a zjednodušení vývoje. 
      Tady bych si dovolil jednu zdánlivě nesouvisející citaci

      “Twenty years ago, when teaching Enterprise #Java Beans, we would sometimes write all the code (and XML config!) in Notepad. This was terrible, but it put ugliness and bad design choices right in your face, all the time. Since then, #Java IDEs have become fantastic, but they sometimes automate around problems rather than solve them. If you write Java code, I challenge you to spend one day a month in a Plain Ole' Text Editor. If your API cannot be casually used from a plain terminal, then your API sucks.”
      A teď ruku na srdce, kdo z vás by si troufnul psát angular kód v notepadu? Nikdo to po vás samozřejmě chtít nebude, ale možná by jste u některých věcí došli k závěru “This is terrible, but it put ugliness and bad design choices right in your face, all the time”

      Překlady

      Angular má pěknou šablonovou internacionalizaci na obsah, atributy, pluralizaci dle ICU,… https://angular.io/guide/i18n


      Protože je ale vše v šablonách, jsou překlady statické. Můžete zbuildovat více verzí aplikace (pro každý jazyk jednu), ale věci jako přepínání za běhu nebo obyčejné použití překladu v kódu není možné. 
      Můžete použít http://www.ngx-translate.com, která tyhle věci řeší, ale přeci jen ve verzi 8 bych už od frameworku tyto vlastnosti čekal.


      Uvedené funkce by se měly v angularu objevit s Ivy (https://docs.google.com/presentation/d/1vdJ46S8SRYp6Bux7nkw3-hpE-XN_L3RK5ZodKyyfmBE/edit#slide=id.g26d86d3325_0_0), takže pokud jste teď přepsali svoji aplikaci na ngx-translate, nemusíte se bát o práci. V brzké době budete moci ngx-translate odstranit a vše přepsat s novou Ivy, knihovna bude totiž deprikovaná https://github.com/ngx-translate/core/issues/495#issuecomment-291158036


      Přiznám se, že dění okolo vývoje frameworku nesleduji úplně pečlivě. O Ivy se mluví už dlouho a někdy mám pocit, že se od ní očekává řešení všech problémů. 


      K průběhu vývoje Ivy snad jen dva obrázky:




      (https://twitter.com/mgechev/status/1052294548385198080 16.10.2018)

      vs



      (https://is-angular-ivy-ready.firebaseapp.com/#/status 13.11.2019)

      Závěr?

      Angular chce být něco jako Spring v Javě - velký, komplexní, vlastně platforma, která bude řešit vše od mobilního po desktopový vývoj. Jako platforma se snaží přinést i všeobjímající tooling. Můj pocit je, že šířka záběru jde na úkor kvality jednotlivých částí.


      Oproti původní verzi se ztratilo JS nejen z názvu, ale i z filozofie frameworku. Když potřebujete funkci, v Angularu vytvoříte objekt, vystavíte ho přes DI a uděláte mu metodu. V JS, když chci funkci, udělám funkci. Toto není dáno TypeScriptem, je to design. Angular se drží OOP stylu a patternů, a když mu budete nutit funkcionální kód, bude se bránit.


      Abstrakce, které Angular bohatě používá, nejsou dle mého názoru dobře zvolené. Často se nevyhnete leaknutí abstrakce do vašeho kódu (zony, changeDetection) nebo duplicitám a složitému “tahání trubek” jako u formulářů. 


      Používání Angularu ve složitější aplikaci se neobejde bez hlubšího studia těchto komplexních abstrakcí, které se bohužel příliš nepotkávají s API, které znáte z JS/DOM, nebo, které by se daly považovat za obecné. Např. rerendering řeší Angular přes svůj Change detector. V Reactu můžete použít memoizaci, což je obecný koncept.


      To můžeme brát jako daň za používání velkého objektově orientovaného frameworku. 


      Zásadní věc, kterou ale Angularu nemůžu odpustit, je, že programátory vede k antipatternům a přesvědčení, že 

      • duplicita je v pohodě - Např. zmiňované subscribe, unsubscribe, markForCheck… se u větší aplikace opakuje u spousty komponent znovu a znovu 
      • haldy generovaného kódu jsou v pořádku - generování vám zjednoduší první napsání, ale co změny? Údržba? Tam vám generátor nijak nepomůže. Nešlo by místo generování 10 řádků psát jen 5? 
      • píší typově bezpečný kód - ve frameworku, který uvnitř staví na any a na pokročilejší možnosti typování rezignuje 
      Občas slyším argumenty, že za kvalitu kódu nemůže framework, že jde o záležitost zkušenosti teamu. Mně ale přijde, že vás Angular k antipatternům vyloženě nabádá. Z dokumentace a doporučených řešení máte pocit, že je to tak v pořádku.


      Od platformy očekávám, že kromě nástrojů dostanu i jednotný styl a best practices. Bohužel, tady Angular opět selhává. Základní API jsou srozumitelná a dobře dokumentovaná, takže první vývojářský dojem bude dobrý, ale co dál? Jakmile narazíte na složitější problémy, najdete spoustu vrstev abstrakce a spoustu nedořešených problémů.
      Největší výzva JS aplikací je správa stavu a s tou vám Angular nijak nepomůže. Můžete se spoléhat na externí knihovny, vybírat mezi patterny, ale to můžete i bez frameworku. 


      Architektura a rozdělení do modulů je také spíše popisována na blozích příznivců než na stránkách frameworku.
      How to návody vyloženě chybí. To vede k tomu, že si ve své aplikaci vytváříte svůj malý framework nad Angularem, který vám zjednoduší práci a sjednotí patterny napříč aplikací.


      Kdysi v dobách AngularJS jsem viděl rozdělení React vs AngularJS jako dvě cesty, kde na té první si můžete sestavit svůj svět z knihoven, které nejvíce sedí na váš problém, jen to vyžaduje větší znalost JS ekosystému. AngularJS pak jako cestu, kterou vám někdo prošlapal a vydláždil, a pokud nepřekročíte omezení daná frameworkem, můžete po ní pohodlně dojít do cíle.


      V případě Angularu 2 - 8 mám pocit, že cesta zdaleka ještě vyšlapána není. Výběr z externích knihoven vás často nemine a bohužel na rozdíl od Reactího světa, kde je svatým grálem JS, jsme tady omezení platformou Angularu, compilerem šablon a AOT kompilací, takže namísto výběru ideálního řešení se občas musíte spokojit s lokálním maximem.


      Jak je patrné, já už jsem si závěr udělal. Angular nepoužívám, nepovažuji ho za dobrý framework. Je ale klidně možné, že vám všechny zmíněné body přijdou marginální. Pak přeji hodně dobrého kódu a úspěšných aplikací.

      Děkuji Víťovi a kolegům z Commity za podněty a připomínky k textu.

      Jak nastavit rodičovskou kontrolu na iOS

      iPad je nejrozšířenějším tabletem na světě, tablety obecně pak jsou prvním vlastním zařízením našich dětí. Má to hned několik praktických

      Příspěvek Jak nastavit rodičovskou kontrolu na iOS pochází z Spajk.cz

      Mám pre teba novú knihu o blogovaní | VLOG #67

      listopad
      20
      Fero Volár
      Mám pre teba novú knihu o blogovaní | VLOG #67

      Uvažuješ nad blogovaním, alebo blog už máš a chceš sa posunúť na ďalší level? Som veľmi rád, že som mohol prispieť k vzniku knihy Tvorba úspešného zarábajúceho blogu. Na tejto knižne sa podieľala 40 autorov zo Slovenska, ale aj Česka. Je písaná prakticky - ľudmi so skúsenosťami z online, email či social media marketingu.

      Jeden výtlačok ti veľmi rád darujem. Viac informácii vo videu. Ale pozor, šancu máš len do 24.11.2019

      Zároveň knihu nájdeš v každom dobrom kníhkupectve: napríklad alian.info/uspesnyblog alebo na alian.info/blogacademy

      Co je to 2FA a proč vícefaktorovou autentizaci používat

      Dvoufaktorová autentizace, dvoufaktorová autorizace, 2FA, dvoufaktor, multifaktorová autentizace, „ta otravná věc když chci poslat peníze a přijde mi SMS“… To

      Příspěvek Co je to 2FA a proč vícefaktorovou autentizaci používat pochází z Spajk.cz

      30 rokov po

      listopad
      17
      Fero Volár
      30 rokov po

      Vybavujú sa mi stále zapnuté čierno-biele televízory s davmi ľudí. Odznaky Verejnosť proti násiliu u babky na chodbe. O nejakú dobu na to nekonečný pochod k rieke Morave. Cez pochmúrne územie, ktorému sa hovorilo pásmo alebo za „drôtami“. Ako sme si mávali s cudzími ľudmi cez rieku. Mal som 6 rokov.

      Až ako dospelý som si uvedomil, že udalosti novembra 1989 sú to najdôležitejšie čo som zažil. Slobodu a demokraciu som nikdy nebral ako samozrejmosť, o to viac posledné roky, keď sa ju poniektorí snažia pošpiniť aj zneužívať.

      Nerozumiem ako môže niekomu chýbať nesloboda, strach, vraždy, zákazy, udávanie. Aj preto si vážim každého, kto vyšiel von a nedal sa zastrašiť. Každého vďaka komu sa to zlomilo. Vážme si, že tu môžeme slobodne žiť a tvoriť.

      Ale ani nezabúdajme, že:

      • z politických dôvodov bolo odsúdených 205 486 ľudí
      • z politických dôvodov bolo popravených: 248 ľudí (247 mužov a 1 žena)
      • vo väzenských zariadeniach zomrelo: asi 4 500 ľudí

      a pri pokusu o prechod československých hraníc so Spolkovou republikou Nemecko a Rakúskom bolo:

      • zastrelených 145 ľudí
      • usmrtených elektrinou 96 ľudí
      • preukázateľne sa utopilo 11 ľudí
      • z obáv pred zatknutím spáchalo samovraždu 16 ľudí
      • zostrelených bolo 5 ľudí
      • v automobiloch havarovaných o pohraničné zátarasy zomrelo 5 ľudí
      • mínami v boli usmrtení 2 ľudia
      • smrť pôsobená zlyhaním organizmu krátko po zatknutí - 1 človek
      • smrť pôsobená služobnými psami - 1 človek

      Fotografia: Aleš Votava, Národní třída, Praha, 17. november 1989. Archív výtvarného umenia SNG, osobný fond Aleš Votava

      Rozhovor s Jaroslavem Tulachem o GraalVM

      listopad
      15
      Openalt.org

      GraalVM – logo

      Pracujete na projektu GraalVM. Graal ale není jen VM – co všechno pod tento projekt spadá a jakými způsoby ho lze používat?

      Graal je opravdu velký projekt. Občas až tak velký, že je těžké na něco zásadního nezapomenout. Ale pojďme to zkusit:

      Weekly #80 - Mirantis kupuje Docker, CDN, Go má 10, Cardboard, SQL Server 2019, Helm 3, MacBook Pro 16”

      listopad
      15
      Fero Volár

      Technológie

      UX & Service design

      Social media & marketing

      Startupy & biznis

      Spoločnosť

      Podujatia

      Kniha týždňa

      Frank Whitford - Bauhaus

      Weekly #80 - Mirantis kupuje Docker, CDN, Go má 10, Cardboard, SQL Server 2019, Helm 3, MacBook Pro 16”

      Weekly #80 - Mirantis kupuje Docker, CDN, Go má 10, Cardboard, SQL Server 2019, Helm 3, MacBook Pro 16”

      Bauhaus – jedna z nejproslulejších škol výtvarného umění nejen 20. století, byl založen roku 1919 v německém Výmaru architektem Walterem Gropiusem a v roce 1933 byl v Berlíně násilně rozpuštěn nacisty. Navzdory své krátké existenci měl zásadní vliv na vývoj výtvarného umění, architektury, grafického, interiérového a průmyslového designu, typografie, módního návrhářství a v neposlední řadě i uměleckého vzdělávání.
      V prostředí Bauhausu působila řada významných a originálních umělců, kteří výrazným způsobem poznamenali rozličná umělecká odvětví, např. Vasilij Kandinskij, Paul Klee a László Moholy-Nagy v malbě, Gunta Stölzl v textilním umění nebo Oskar Schlemmer ve scénografii.

      Sleduj ma na goodreads.com/FeroVolar

      Stanovisko Sdružení pro internetový rozvoj (SPIR) k návrhu zákona o dani z vybraných digitálních služeb

      Stanovisko Sdružení pro internetový rozvoj (SPIR) k návrhu zákona o dani z vybraných digitálních služeb tereza.tumova@… Čt, 11/14/2019 - 15:20
      13. 9. 2019

      Sdružení pro internetový rozvoj (SPIR) podporuje přístup Ministerstva financí založený na úvaze, že současný daňový systém již neodpovídá skutečné situaci na trhu, kde technologický pokrok umožňuje společnostem vykonávat intenzivní ekonomickou činnost i v zemích, v nichž nejsou fyzicky usazeny. Dochází tak k tomu, že společnosti vykonávající obdobnou aktivitu na témže trhu nemusí vždy podléhat v příslušné zemi stejné míře zdanění. 

      V současnosti nadnárodní technologické společnosti odvádějí do českého státního rozpočtu výrazně nižší daně než jejich čeští konkurenti, což vytváří nerovné tržní podmínky a brání dalšímu rozvoji českého digitálního průmyslu a posilování jeho konkurenceschopnosti v rámci EU i globálně.

      Z tohoto důvodu SPIR v obecné rovině podporuje záměr předkladatele návrhu na zavedení daně z vybraných digitálních služeb, jíž mají podléhat digitální služby poskytované na českém trhu globálními společnostmi, které nejsou v České republice usazené, a tudíž neodvádí příslušné daně (zejména daň z příjmu) dle daňových předpisů platných v České republice.

      Bohužel však návrh zákona podle názoru SPIR vykazuje i celou řadu nedostatků a nepřesností, které ve svém důsledku mohou způsobit interpretační nejednotnost a následně soudní spory, a to aniž by byl naplněn účel tohoto nového předpisu. 

      Navrhovaný zákon může zároveň svou konstrukcí vést k řadě nezamýšlených důsledků, z nichž nejzávažnějším se jeví podstatné znevýhodnění podniků, které se budou přesouvat z kategorie malých podniků do kategorie podniků středních či se budou stávat součástí nadnárodních struktur (které ovšem nemusí být zaměřené na činnost v oblasti digitální ekonomiky). Návrh může u takových podniků, které již dnes řádně daní své příjmy v České republice, vést k tak razantnímu navýšení daňové zátěže ve srovnání s jejich konkurenty, kteří využívají výhod zemí s nižším daňovým zatížením, že již nadále nebudou ve vztahu k nim konkurenceschopné. Jsme přesvědčeni, že návrh zákona v aktuálním znění tak může značně omezit jak schopnost českých podniků prosadit se na evropském a globálním trhu, tak schopnost získat kapitálové zdroje na další rozvoj.

      Návrh tak sice nedopadne na malé podniky, ovšem těm podnikům, které se díky svému umu a schopnostem začnou dostávat do situace, že by mohly byť vzdáleně konkurovat nadnárodním gigantům (které hradí v České republice a v EU v poměru ke svému obratu nepoměrně nižší daně), může efektivně bránit v tom, aby dosáhly potřebné konkurenceschopné velikosti.  

      Domníváme se proto, že by návrh zákona měl být před dalším projednáváním předmětem dodatečné odborné diskuze, v níž by byla zhodnocena i rizika pro českou ekonomiku, jež s sebou tento návrh nese.

      Závěrem

      SPIR podporuje narovnání tržních podmínek, a vítá proto iniciativu předkladatele, avšak upozorňuje, že návrh vyžaduje hlubší diskusi nad jednotlivými články a v některých případech řadu korekcí tak, aby mohlo být dosaženo zamýšleného účelu. Kvalita nového předpisu bude rozhodovat o tom, zda budou vytvořeny rovné podmínky na trhu, z nichž budou moci české společnosti oproti stávající situaci spravedlivě profitovat, anebo zda dojde k odlivu českých společností do jiných zemí EU s přívětivějšími daňovými podmínkami.

      SPIR je rovněž připraven spolupracovat s kompetentními úřady při přípravě finální podoby předpisu tak, aby nový zákon reflektoval v plné míře nejen politickou vůli, ale také realitu českého digitálního trhu.

       

      Stanovisko najdete ke stažení ve formátu .pdf níže pod článkem.

       

      O'Reilly Velocity Conference 2019 v Berlíne | VLOG #66

      listopad
      14
      Fero Volár
      O'Reilly Velocity Conference 2019 v Berlíne | VLOG #66

      Konferencia Velocity je pre mňa každoročný sviatok. Minulý rok sa konala v Londýne, tento sa presunula do Berlína. A rovno môžem povedať, že nesklamala a udržala si svoj vysoko nastavený štandard.

      Občas mám pocit, že sa mení so mnou – prvý raz ma zaujímali skorej viac technické veci, ísť do hĺbky. Tento rok som si vybral témy, ktoré sa venovali budovaniu a komunikácii v tíme, mikcroservices a monitoringu. Viac už vo videu.

      Eventu som sa zúčastnil vďaka O'Reilly Media a WebSupport.sk

      Pozvánka na 170. sraz OpenAlt – Brno

      listopad
      13
      Openalt.org

      Listopadový brněnský sraz spolku OpenAlt + fandů svobodného přístupu + těch, co už husu nemohou ani vidět, se koná v pátek 2019-11-15 od 18:00 v restaraci Vegalité (Slovákova 10, Brno). Témata? Co dům dá..

       

      WeAreDevelopers Congress je pre vývojárov zaujímajúcich sa o AI, Cloud, blockchain a IoT

      listopad
      13
      Fero Volár
      WeAreDevelopers Congress je pre vývojárov zaujímajúcich sa o AI, Cloud, blockchain a IoT

      WeAreDevelopers predstaví odborníkov v oblasti cloudu, umelej inteligencie, blockchainu a IoT. Po veľkom minuloročnom úspechu sa opäť zameria na najdynamickejšie témy týkajúce sa vývoja softvéru.

      WeAreDevelopers Congress Vienna 2019 otvorí Tanmay Bakshi, pätnásťročný expert na umelú inteligenciu. Zaujímavé sú určite aj ďalšie mená ako Leo Shiwei Li (President of Tencent cloud Europe), Cassie Kozyrkov (Chief Decision Scientist at Google), Siddha Ganju (Solution Architect at Nvidia), Or Levi (Data Science Team Lead at eBay) či Nils Heuer (Global Solutions Architect at Amazon Web Services) a mnohí ďalší. Podrobný zoznam rečníkov, ale už aj program nájdete na stránke wearedevelopers.com.

      Program je vyskladaný tak, aby poskytol prehľad o nových technológiách, ako je umelá inteligencia alebo blockchain, ktoré budú poháňať nové obchodné modely. Misiou podujatia je inšpirovať ľudí, poskytnúť príklady použitia v praxi a povzbudiť ich, aby tieto technológie používali, čím môžu priniest pridanú hodnotu svojim vlastným softvérovým projektom.

      WeAreDevelopers Congress je pre vývojárov zaujímajúcich sa o AI, Cloud, blockchain a IoT

      Témy siahajú od toho, ako zisťovať fake news, vytvárať API, používať deep learning v rôznych odvetviach, využívať čo najviac cloudových AI prostredí a ešte oveľa viac.

      WeAreDevelopers Congress Vienna 2019 sa bude konať už koncom tohto mesiaca, konkrétne 28. a 29. novembra priestoroch Viedenského paláca Hofburg, kde sa pravidelne konáva aj napríklad Pioneers.

      Vstupenky sú už k dispozícii už od 199 eur, len do 15. novembra. Potom bude cena dvojnásobná. Myslím, že podľa programu ide o veľmi dobrý pomer cena/výkon.

      Po 15 letech návrat ke stolnímu počítači

      listopad
      11
      Jiří Eischmann

      Poslední půlrok byl nabitý životními událostmi: oženil jsem se, narodila se mi dcera a bohužel mi taky umřel taťka. Po něm mi zůstal stolní počítač, kterým jsem se rozhodl vybavit pracovnu v novém bytě (ano, ještě jsem se do toho všeho přestěhoval).

      Stolní počítač nemám od roku 2004, kdy jsem přesunem na vysokoškolské koleje de facto přestal bydlet u rodičů. Za to, že jsem se dostal na vysokou školu, jsem od taťky dostal zánovní notebook Acer TravelMate 220. Od té doby už jsem fungoval pouze na noteboocích. Buď na pracovním nebo na domácím, což byl poslední léta ten, který jsem dřív používal v práci a který jsem si posléze odkoupil.

      Stolní počítač, který jsem zdědil, nebyl žádné dělo: Barbone od T.S.Bohemia z roku 2013, ještě z doby, kdy tato firma prodávala počítače s Linuxem. Intel Core i3-3220 CPU @ 3.30GHz, 8 GB RAM DDR3, AMD Radeon 667D3 (pokud byste ji někdo chtěl, rád se jí zbavím), několik harddisků různého stáří a kapacity.

      Počítač byl sice na běžnou kancelářskou práci dostatečně svižný, ale řekl jsem si, že když mít stolní počítač, tak ať se na něm dají hrát slušně i hry, proto jsem se ho rozhodl upgradovat. Jako grafickou kartu jsem vybral SAPPHIRE PULSE Radeon RX 570 8G. Nechtěl jsem měnit zdroj a u výkonnějších karet bych mohl narazit na jeho limit, který je jenom 400 W. K tomu SSD Samsung 860 EVO 500GB, protože harddisky byly nejužším hrdlem výkonu počítače, a operační paměť jsem rozšířil na 16 GB.

      K počítači byla taky licence na Windows, tak jsem si říkal, že když už tu licenci mám, využiji ji a Windows si nainstaluju do dual bootu. To by další obnovená premiéra, protože Windows jsem neměl na počítači minimálně 13 let. Jak se následně ukázalo, stálo mě toto rozhodnutí hodně času a stresu.

      Poradili mi, že mám Windows první nainstalovat a až poté upgradovat hardware, aby se nestalo, že si Windows budou myslet, že mám nový počítač. Nainstaloval jsem tedy Windows a poté Fedoru. Nevšiml jsem si ale, že v BIOSu je nastavené „UEFI & Legacy Mode“, a Windows se mi nainstalovaly v UEFI módu a Fedora v legacy. Dělalo to problémy s dualbootem, takže jsem Fedoru přeinstaloval, aby byly oba v UEFI.

      Následně jsem vyměnil grafickou kartu. Asi hodinu jsem řešil, proč nemám žádný obraz na monitoru. Nakonec jsem zkusil vyměnit DisplayPort kabel za HDMI a najednou jsem obraz měl (později jsem zjistil, že kabel je v pořádku, asi je špatný DP konektor na monitoru). Fedora nabootovala, jakoby se nic nezměnilo, ale Windows skončily na modré obrazovce smrti. Zpětně jsem se dozvěděl, že při upgradu grafické karty je potřeba staré ovladače odstranit, potom nabootovat v nějakém základním grafickém režimu a potom nainstalovat ovladače nové. Tady jsem nakonec skončil u obnovy systému do původní instalace, která tak nebolela vzhledem k tomu, že byl systém čerstvě nainstalovaný.

      V BIOSu jsem si taky všiml, že disky jsou připojené přes IDE, což zbytečně limituje výkon SSD. Když jsem přepnul na AHCI, Fedora opět naprosto bez problémů. Windows to opět nerozdýchaly -> modrá obrazovka smrti. Musel jsem přepnout na IDE a nastudovat, že je potřeba nastavit, aby Windows bootovaly do záchranného režimu, kde je možné nainstalovat ovladače pro AHCI.

      Po upgradu BIOSu jsem se několikrát dostal do boot loopu. 14 dní jsem používal Fedoru a nic a pak jednou přepnul do Windows a dřív nebo později skončil v boot loopu a musel BIOS resetovat. Už jsem fakt nevěděl, co s tím, a byl jsem nalomený, že si koupím úplně novou desku s Ryzenem, ale to bych nakonec obměnil celý počítač a pořádně se prohnul (základní deska, procesor, paměti, zdroj). Nakonec jsem upgradoval na úplně poslední verzi BIOSu, který má označení „beta“, a ponechal co nejvíce voleb v BIOSu na výchozích hodnotách. Víceméně jsem jen přepnul z IDE na AHCI. A už měsíc to drží. Magie 🙂

      Problémy jsem měl ještě s WiFi kartou. Ta nebyla přímo na základní desce, ale dokoupená. I když byl AP jen dva metry od antény, spojení bylo hodně špatné. Nakonec jsem koupil za pár stovek switch a po ethernetu připojil i počítač. Na základní desce nebyl ani Bluetooth adaptér, takže jsem dokupoval jeden do USB. V českých eshopech není popravdě moc na výběr. Já bral ten od Asusu, ale jsou to víceméně všechno stejné čipy pouze s podporou Bluetooth 4.0 jen pod jinou značkou. Bohužel není úplně bezproblémový. Občas mám problémy k němu připojit sluchátka a to jak ve Fedoře, tak ve Windows. Objednal jsem si v Číně adaptér s podporou Bluetooth 5.0, tak až dojde, uvidím, jestli bude lepší.

      K počítači mám 24″ WQHD (2560×1440 px) monitor a i když tenkrát patřil k těm levnějším kouskům, oproti FullHD je to znatelné zlepšení v jemnosti displeje. A pořád člověk nemá problém s výkonem (u her) a škálováním jako u 4K monitorů. S grafickou kartou jsem zatím taky hodně spokojený. Nvidia mi kvůli svojí (ne)podpoře Linuxu nesmí přes práh. Karty od AMD jsou na tom díky open-source ovladačům přímo v jádře mnohem lépe a tady se mi to jen potvrdilo. Snad začne AMD časem zatápět Nvidii na trhu s grafikami stejně jako nyní zatápí Intelu na trhu s procesory. Nvidie by to potřebovala jak prase drbání.

      Po tom všem mám teď spolehlivý stolní počítač. Musím říct, že jsem za těch 15 let úplně zapomněl, jaká je to zábava skládat si počítač 😀 Na noteboocích jsem maximálně měnil disk nebo klávesnici. Musím poděkovat Kamilovi Páralovi, který mi na Telegramu trpělivě radil s věcmi, které jsem nikdy nevěděl nebo už zapomněl.

      A musím říct, že si návrat ke stolnímu počítači užívám. Mám dostatek výkonu, dostatek portů na připojení dalších zařízení, velkou flexibilitu, kdy můžu jednu komponentu vyměnit za jinou, když nebude vyhovovat. Nahrává tomu i změna životního stylu. Dřív, když jsem byl mnohem víc na cestách, mi víc vyhovoval notebook. Teď jsem víc doma s rodinou a nemám problém s nepřenosným stolním počítačem. Když pracuji z domu, tak pracuji taky z něj. Kvůli pohodlí. Mám vytvořený speciální uživatelský účet, abych měl oddělená data a hlavně abych tam neměl k dispozici „rušiče“ koncentrace.

      A jak jste na tom vy? Máte ještě někdo stolní počítač?

       

       

      Pred 30 rokmi padol Berlínsky múr | VLOG #65

      listopad
      11
      Fero Volár
      Pred 30 rokmi padol Berlínsky múr | VLOG #65

      Dnes je to presne 30 rokov, čo padol symbol Studenej vojny a Európou sa začala šíriť vlna slobody. A tá dorazila až do Československa. Ako za jednu noc múr vznikol, tak aj padlo. Čo tomu predchádzalo sa dozviete vo videu. Točil som priamo v Berlíne dva dni pred oslavami 30. výročia pádu Berlínskeho múru.

      Jak nastavit rodičovskou kontrolu na Androidu

      Pokud chcete ochránit své děti nejen před nevhodným obsahem, bude dobré již od mala nějakým způsobem obsah vybírat, revidovat a

      Příspěvek Jak nastavit rodičovskou kontrolu na Androidu pochází z Spajk.cz

      Pozvánka na 170. sraz OpenAlt – Praha

      listopad
      08
      Openalt.org

      Listopadový pražský sraz spolku OpenAlt se koná ve čtvrtek – 14. 11. 2019 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tématem bude vyhodnocení konference a plány na další rok.

      Weekly #79 - Golemio je open-source, RHEL 8.1, podvádzať na daniach nebolo jednoduchšie

      listopad
      08
      Fero Volár

      Technológie

      UX & Service design

      Social media & marketing

      Startupy & biznis

      Spoločnosť

      Podujatia

      Kniha týždňa

      Cal Newport - Digitálny minimalizmus

      Weekly #79 - Golemio je open-source, RHEL 8.1, podvádzať na daniach nebolo jednoduchšie

      Weekly #79 - Golemio je open-source, RHEL 8.1, podvádzať na daniach nebolo jednoduchšie

      Technológie vo svojej podstate nie sú ani dobré, ani zlé. Kľúčom je používať ich na to, aby vám vo vašich cieľoch a hodnotách pomáhali, a nie nechať sa nimi využiť. Táto kniha vám ukáže ako na to. Na celom rade príkladov zo skutočného života vysvetľuje autor bežné návyky digitálnych minimalistov a myšlienky, na ktorých sú založené. Ukazuje, ako prehodnotiť svoj vzťah k sociálnym sieťam, znovu objaviť potešenie zo sveta „offline“ a prináša stratégie, ako tieto návyky začleniť do vášho života.

      Sleduj ma na goodreads.com/FeroVolar

      Svoboda v uspořádání slov

      Ne každý příspěvek na tomto blogu je původní, poměrně často se jedná o překlad. Někteří se občas ptají: „Není to zbytečné, nemůžou si lidí přečíst originál?“ Podle mě je cizí jazyk vždycky bariéra, i kdyby malá. Sami sebe se zeptejte, jaký text se vám čte snadněji, zda anglický nebo český. K překladu mě vede několik důvodů. Především se musí jednat o text, který mě zaujme, o kterém si myslím, že by stálo za to, aby si ho přečetli i ostatní (třeba už jen tím, že se o něm dozvědí a klidně skočí rovnou na originál). Dále jde o téma, kterému jsem ochotný věnovat nějaký čas, který budu trávit překladem. Zároveň mám při překladu možnost hlouběji vnímat autorův styl psaní a lecčemu se přiučit. V neposlední řadě, jak řekl někdo chytřejší než já, přestane-li jazyk používat odborná veřejnost, jazyk začne umírat. Překlady technických článků nejsou v jiných oborech ojedinělé. Taky se musím přiznat, že mi to vytrhne trn z paty, pokud zrovna nemám inspiraci psát text vlastní.

      Když mi na Zdrojáku vyšel můj překlad článku Baristická lekce v nabírání, tak se sešlo spoustu připomínek. Od takových, které zpochybňovaly překlad here be dragons na zde jsou lvi, přes užitečnější (které jsem zapracoval), až po mnoho připomínek týkajících se slovosledu, kterému prý kouká angličtina z kapsy. To je možné. Ovšem chtěl bych připomenout, že nepřijde žádná jazyková policie, která by mi udělila pokutu, jelikož se slovosledem si v češtině můžete velmi dobře hrát. Ostatně moc pěkně o tom pojednávají Toulky českou minulostí - 618. schůzka: O hatmatilce, kdákání, šaškové haleně a clu na cizí slova

      Náš jazyk má před jinými tu přednost a výbornost, že může tvořit všecky druhy básní, jaké zná latina a řečtina, nejenom v rytmu, ale i v metru po latinském a řeckém způsobu s nejvyšším půvabem a jemností. Ale ještě větší přednost, jíž se smí chlubit zároveň s latinou, je v tom, že se v ní konaly po dlouhou dobu mše svaté, stejně jako ostatní církevní obřady. A konečně ještě jedna mluvnická přednost, jakou má jenom velice málo jazyků: totiž svoboda v uspořádání slov. Slova se smějí libovolně přemisťovat a smysl řeči přitom nijak netrpí. Příklad: Já miluji pána Boha našeho. Já našeho Pána Boha miluji. Miluji já našeho Boha, pána. Pána Boha našeho miluji. Miluji já našeho Pána Boha. Našeho pána Boha miluji já. Pána našeho já miluji Boha. Je možno přemístit v německé řeči slova tak často? Jistě ne. To je přednost, jíž se smí chlubit - pokud vím - jenom latina.

      Nechci se jen vymlouvat, zajisté je mnoho mých vět kostrbatých. Proto jsem se od kamarádky, která se překladatelstvím živí, nechal poučit, že lingvisté používají pojem aktuální členění větné a to, že jednotlivé výrazy ve výpovědi se liší svou výpovědní dynamičností.

      Přestože jsem na pravopisné chyby u jiných pes a souzním s článkem Proč nezaměstnám lidi s mizernou gramatikou (ostatně proto jsem ho překládal), tak je jasné, že bez redaktora a korektora se tento blog bude hemžit chybami.

      Jak psal Jiří Levý: „Překlad je jako žena, buď věrný, nebo hezký.“. Dokonce i v odborných textech může být něco krásného. Proto jsem live edge wooden tables přeložil dřevěné stoly z nesámovaných prken a i kdyby to nebyla pravda, je to pořád krásnější, než napsat prostě a pouze stůl. Protože Ivan Olbracht říká, že první pravidlo je, aby spisovatel nepsal na stromě seděl pták, ale na olši seděl strnad.

      Závěr

      Překladatelství je dřina, určitě bych se tím neuživil. Ne všechno, co si myslíte, že je chyba, jí opravu je. Budu v překládání pokračovat, protože mi to dává smysl. Neztrácím naději, že se časem třeba zlepším. Připomínky vítám.

      Související

      Jak odinstalovat Edge

      Pokud používáte jiný prohlížeč a MS Edge Vás otravuje, nebo ho z jakéhokoliv důvodu nechcete, je možné jej odinstalovat. Osobně sice

      Příspěvek Jak odinstalovat Edge pochází z Spajk.cz

      Facebook je po novom FACEBOOK

      listopad
      05
      Fero Volár
      Facebook je po novom FACEBOOK

      Spoločnosť Facebook, Inc. ktorá stojí za rovnomennou sociálnou službou predstavila nové logo. V ňom sa názov spoločnosti píše veľkými písmenami. Ide o snahu oddeliť čo je firma, teda FACEBOOK a čo je sociálna sieť a teda Facebook.

      Nové logo by sa malo objaviť hlavne v aplikáciach, ktoré si ľudia menej spájajú práve s touto spoločnosťou ako Instagram, Oculus či WhatsApp a ďalšie.

      Facebook je po novom FACEBOOK

      Sám som veľmi zvedavý či im v tom práve takýto rebranding pomôže. Taký Google na to išiel výrazne razantnejšie a v roku 2015 vznikol Alphabet.

      Facebook je po novom FACEBOOK

      GitLab - nástroj na správu, verzování, CI/DI a vedení projektů

      listopad
      04
      Josef Jebavý
      Pokud se něco dělá (typicky vývoj software) jedná se obvykle o projekt a ten je potřeba nějak vést. I malé úkoly je potřeba vést, i když na to obvykle stačí, provádět pravidelný zápis. Je potřeba zapisovat informace o projektu - tedy tvořit dokumentaci. Zdrojové kódy programu je potřeba verzovat, to proto, aby jste se mohli efektivně orientovat v postupném vývoji a nasazovat efektivně změny. A ideální je rutinní prací automatizovat. S tím vším pomůže software GitLab.

      Jak nastavit rodičovskou kontrolu ve Windows

      Pokud máte ratolesti, dříve nebo později budete tuhle otázku řešit. A věřte mi, je lepší ji řešit dříve, než později.

      Příspěvek Jak nastavit rodičovskou kontrolu ve Windows pochází z Spajk.cz

      Weekly #78 - Electron 7, UX, zbohom Flash, Fedora 31

      listopad
      01
      Fero Volár

      Technológie

      UX & Service design

      Social media & marketing

      Startupy & biznis

      Spoločnosť

      Podujatia

      Kniha týždňa

      Robert Holman - Dějiny ekonomického myšlení

      Weekly #78 - Electron 7, UX, zbohom Flash, Fedora 31

      Weekly #78 - Electron 7, UX, zbohom Flash, Fedora 31

      Mottem knihy je myšlenka, že ekonomii nelze plně pochopit bez poznání její historie. Autoři zvolili kombinaci historického a teoretického přístupu. Chtěli tak ukázat, že nestačí studovat soudobou ekonomii bez znalosti její historické geneze a také že nelze ignorovat ty myšlenkové směry, které nejsou součástí soudobého „hlavního proudu“. Kombinace historického a teoretického přístupu má své výhody. Čtenář může v rámci jednotlivých kapitol sledovat, jak se vyvíjely jednotlivé tradice ekonomického myšlení, jaké jsou jejich přínosy i jejich nedostatky. Může je porovnávat a na těchto komparacích třídit své ekonomické myšlení.

      Sleduj ma na goodreads.com/FeroVolar

      Konference OpenAlt 2019 je tento víkend

      říjen
      31
      Openalt.org

      Čtrnáctý ročník konference OpenAlt spojí a otevře komunity z různých oborů. V Brně se sejdou vývojáři, lidé ze státní správy, učitelé, vědci, ale i domácí kutilové. Společným tématem bude otevřenost.

      https://openalt.cz/2015/img/logo-openalt-conference.png

      Tags: 

      Fedora 31 Silverblue

      říjen
      30
      Martin Vician

      Už přes pět měsíců používám Fedoru Silverblue. Začal jsem s ní chvíli po vydání Fedory 30, takže jsem až nyní měl možnost upgradovat na nový release. A můžu říct, že to bylo rychlé a snadné.

      Fedora 31 Official image

      Číst dál… (1 min zbývajících)

      Vývoj vpsAdminOS, NFS na stagingu, overlay2 driver pro Docker a další

      říjen
      29
      vpsFree.cz

      Přináším zase nějaké nové informace o přechodu na vpsAdminOS a čemu jsme od posledního reportu v červnu věnovali. Píšu po dlouhé době, takže je to jaksi… delší. To nejdůležitější je na začátku.

      Aktuální stav

      Ke spuštění produkčního nodu s vpsAdminOS nyní zbývá dořešit přístup k NFS. Dlouho jsme hledali nějaký funkční model pro přístup k nasboxu z OpenVZ a vpsAdminOS a to se nám teď snad podařilo, podrobněji viz níže.

      S následným přechodem OpenVZ -> vpsAdminOS to aktuálně vidíme tak, že přidáme jeden další produkční node s vpsAdminOS, na který budeme VPS ze stagingu individuálně přesouvat. IP adresy měnit nebudeme. Nové členy budeme umisťovat na nový systém, stávající VPS poběží nadále na OpenVZ. Kdo chce, se bude moct na nový systém přesunout, ale v dohledné době k tomu nikoho tlačit nebudeme.

      NFS v produkci a na stagingu

      V posledním reportu jsem naznačoval, jakým způsobem budeme řešit exporty a mounty datasetů na vpsAdminOS. Ačkoli by to fungovalo, mělo to jednu zásadní nevýhodu: jeden NAS dataset by nešel připojit najednou do OpenVZ a vpsAdminOS VPS, resp. jeden z těch dvou systémů by neměl přistup k datům. Dalo by se s tím žít, ale byla by to pro nás všechny zbytečná zátěž při migraci VPS.

      Zmiňoval jsem taky, že do kernelu 5.2 byla do NFS klienta přidána podpora pro user namespaces. Zkusili jsme tedy ve VPS povolit mountování NFS a ono to funguje. Na NFS server chodí ID uživatelů a skupin tak jak je vidí VPS, resp. user namespace, takže není problém sdílet data s VPS na OpenVZ.

      Znamená to však zásadní změnu v přístupu k nasboxu. Na OpenVZ to funguje tak, že si mount naklikáte ve vpsAdminu a ten ho připojí, ani vás nemusí zajímat jakým způsobem to funguje. Na vpsAdminOS to takto být nemůže. Aby na NFS server chodily správné UID/GID, je potřeba mountovat zevnitř VPS. Kernel si totiž pamatuje, v jakém user namespace mount vytvoříte a podle toho se chová.

      Pro staging/vpsAdminOS se ve vpsAdminu nebudou nastavovat mounty ve VPS, ale exporty na NFS serveru. Nastavíte si, jaké VPS mají mít k danému datasetu přístup a vpsAdmin vám zobrazí adresu a cestu k exportu, který si z VPS sami mountnete. Ve vpsAdminu najdete ukázkový příkaz pro mount, záznam v /etc/fstab, nebo i systemd mount unit. Ve VPS samozřejmě musíte mít nainstalovány utility pro práci s NFS. Nově tak máte pod kontrolou jednak více možností u nastavení exportu (ro/rw per host, root_squash, sync, atd.) a taky si můžete zvolit libovolné nastavení mountu. Akorát nepoužívejte –oproto=udp, nefunguje to spolehlivě a budeme to vypínat.

      Problém zůstává se sdílením (sub)datasetů VPS. To zatím nebude možné, žádné ideální zatím řešení nemáme. Předpokládám, že v budoucnu si budete moct sdílet data mezi VPS tak, že si uvnitř spustíte NFS server. To se ještě uvidí, jak moc to bude hořet. Jedno z use-case, které tímto zaniká, je možnost opravy nestartující VPS tak, že si jeho disk připojíte do jiné VPS. Místo toho plánuju do vpsAdminu přidat možnost nechat VPS nastartovat z čisté šablony distribuce, ze které se do rozbitého systému dostanete podobně jako když nabootujete live systém.

      Toť tedy aktuální plán zprovoznění nasboxu na stagingu. Všechno už máme nasazeno, můžete to začít používat. A prosím hlásit na podporu když na něco narazíte. Abych to shrnul:

      • do OpenVZ VPS se datasety a snapshoty připojují tak jako doposud
      • na vpsAdminOS místo mountu z vpsAdminu vytvoříte export datasetu/snapshotu a ten si z VPS mountnete sami
      • jeden dataset/snapshot může být exportován jen jednou, připojen kdekoli (i na OpenVZ)

      Více viz článek na naší KB.

      Nějaký čas to takto necháme běžet. Pokud nenarazíme na nějakou komplikaci, můžeme vpsAdminOS spustit na ostro. Budeme čekat minimálně na Linux 5.4, protože to bude LTS, na kterém budeme moci zůstat delší dobu.

      Storage driver Dockeru

      Hlavní problém dockeru na vpsAdminOS byla nefunkčnost pořádného storage driveru. Doposud u nás fungoval jen VFS driver a ten je značně neefektivní. Při vytváření každé vrstvy kontejneru totiž kopíruje data na disku sem a tam. Proto u nás byl docker pomalejší než jinde. TL;DR je, že se nám podařilo zprovoznit overlay2 driver díky tomu, že snajpa do ZFS dodělal podporu pro overlayfs. Cesta ale byla trnitá.

      Výchozím driverem v dockeru je overlay2 založený na overlayfs. Ten bohužel stále nefunguje nad čistým ZFS, protože kernel vyžaduje implementaci určitých flagů v renameat2(). Další problém je, že se ZFS pro kernel tváří jako „remote filesystem“ a vyžaduje revalidaci dentries, což overlayfs nedělá.

      Docker obsahuje taky ZFS driver, ale ten nejde uvnitř VPS použít, protože ZFS nepodporuje user namespace a není jasné, jak by to vůbec mělo fungovat. Tzn. nemáme jak bezpečně předat dataset z hostitele do VPS. Nakonec by to asi ani nebyl dobrý nápad, ZFS je sice super když zrovna nepanikaří, ale přináší to i různé komplikace, které stačí že musíme řešit na hostiteli.

      Dalším z možných driverů je AUFS. Jedná se o předchůdce overlayfs, který obsahuje více funkcí, ale nikdy se do Linuxu nedostal. Zkoušeli jsme ho přidat do kernelu na stagingu, i tak ho docker stejně sám o sobě nevyužije, protože si myslí, že AUFS v user namespace nefunguje a nevyzkouší to. Když se docker opatchuje, s AUFS funguje a je to mnohem svižnější. Bohužel by to vyžadovalo instalaci dockeru z našich repozitářů, o které bychom se museli starat. Navíc je AUFS v dockeru označený za překonaný a je možné, že ho odstraní. Pak bychom si jej museli udržovat sami.

      Nakonec se nám povedlo přizpůsobit si ZFS tak, aby nad ním fungoval overlayfs. Máme na to pull request, začleněn zatím nebyl.

      Pokud si myslíte, že pak docker sám od sebe použije overlay2 driver a všechno bude super, tak jste na omylu. Samozřejmě mají v kódu natvrdo zapsáno, že na ZFS to nefunguje. Takže dockeru z kernelu lžeme a říkáme mu, že na ZFS neběží… a pak teda funguje. Hurá.

      Nasazeno už to máme několik týdnů a podle ohlasů jsou buildy kontejnerů mnohem rychlejší. Jediný zádrhel byl bug v našem overlayfs patchi, který rozbil účtování zabraného místa při přesouvání/mazání souborů. Zabrané místo nešlo uvolnit a postupně se kvůli tomu zaplňovaly kvóty datasetů VPS. Bylo to způsobeno tím, že jedna důležitá funkce byla volána z ASSERT makra, které je implementováno jen v debug buildech, takže s vypnutým debugem to nic nedělalo.

      Docker-in-Docker

      Další chuťovka je docker v dockeru, používá se to např. na nějaké CI v gitlabu. U nás to samo od sebe nefunguje, protože se to při startu pokouší o mount -t securityfs, což ve VPS s user namespace nejde. Zatím se nám nepodařilo kernel upravit tak, aby to prošlo, ale pokud na to někdo narazíte, má to jednoduchý workaround, stačí přidat volume:

      $ docker run -v /sys/kernel/security:/sys/kernel/security ...
      

      osctl-exportfs

      Na nasboxu nám dlouhodobě chybí možnost zjistit kdo a jak ho využívá v případě, že disky přestávají stíhat. Kernel 5.3 přináší podporu NFS serveru v network namespace a to nám přináší zajímavé možnosti.

      osctl-exportfs je nástroj z vpsAdminOS pro vytváření malých kontejnerů pro NFS servery, kde každý server má vlastní IP adresu a sadu exportů. Funguje to tak, že když si ve vpsAdminu nastavíte export, spustí se vám dedikovaný NFS server. vpsAdmin pak bude schopen počítat přenesené data či sledovat využití jednotlivých NFS serverů.

      syslog namespace

      Během prázdnin jsme do kernelu přidali syslog namespace, tzn. z VPS je číst log z kernelu, à la dmesg. Můžete tam vidět zprávy od OOM killeru, logy z iptables a další.

      Nastavení oom_score_adj

      Přidali jsme do kernelu výjimku, aby bylo možné ve VPS libovolně nastavovat /proc/<pid>/oom_score_adj. Můžete tak chránit důležité procesy před OOM killerem, např. sshd. Minimálně distribuce se systemd to využijí automaticky.

      Restrikce /sys

      Část /sys je sdílená mezi hostitelem a všemi VPS, část se přizpůsobuje např. network namespace. Změnili jsme oprávnění citlivých adresářů tak, aby se k nim z VPS nedalo přistupovat. Může se stát, že s tím nějaký program bude mít problém, např. museli jsme trochu ustoupit libvirtu. Pokud narazíte na něco dalšího, tak se ozvěte.

      vpsfree-cz-configuration a monitoring

      Během prázdnin jsem z velké části předělal konfiguraci našich vpsAdminOS nodů a NixOS serverů/VPS. Konfigurace systému se teď definuje na jednom místě pro různé výstupy, jako netboot server a aktualizace systému naživo.

      V konfiguraci serveru je možné se odkazovat na adresy, služby a porty ostatních systémů v clusteru, což se hodí třeba na propojování služeb, přesné nastavení firewallu, nebo generování DNS. Máme taky nový monitoring, který automaticky hlídá všechny systémy, které jsou součástí konfigurace.

      Nový monitoring je postavený nad prometheusem, alertmanagerem a používáme taky centralizované logování přes graylog. Sledujeme teď více parametrů, které nám způsobovaly problémy. Řešil jsem to hlavně kvůli častým výpadkům při ZFS panics, které nás trápily od začátku prázdnin. Původní monitoring úplně selhával a o tom, že node přestal ve 4 ráno provádět diskové operace, jsme se dozvěděli až když se někdo z nás probudil.

      Aktuálně logy ze všech nodů zpracovává graylog a pokud dojde k ZFS panic, pošle o tom alert přes alertmanager. Do minuty tak máme SMS. Je zde ještě hodně co ladit, zejména doručování SMS různým lidem v různých časech, abychom se z toho nezbláznili. Na to jsem bohužel existující řešení zatím nenašel.

      Do budoucna bych taky chtěl členům zpřístupnit grafanu s daty z prometheuse jako náhradu muninu, ale těch parametrů k zobrazení je tam strašně moc a je potřeba tomu věnovat více času, který teď nemáme.

      Buildbot pro vpsAdminOS

      Už mnoho let toužíme po nějaké formě CI a zajišťování QA pro kontrolu aktualizací či nové funkcionality. Trochu to sice komplikuje fakt, že nemáme naprosto žádné testy, ale nenašli jsme ani žádnou technologii, nad kterou bychom to chtěli postavit. Teď jsem s tím trochu pohnul, repozitář vpsAdminOS hlídá Buildbot a při změně ho automaticky sestavuje. Vypadá to celkem použitelně a postupem času bychom toho chtěli více. Už teď je to užitečné zejména pro plnění binární cache, ze které lze stahovat naše buildy kernelu, ZFS, atd. Na NixOS se dá použít takto:

      nix = {
          binaryCaches = [
            "https://cache.vpsadminos.org"
          ];
          binaryCachePublicKeys = [
            "cache.vpsadminos.org:wpIJlNZQIhS+0gFf1U3MC9sLZdLW3sh5qakOWGDoDrE="
          ];
        };
      

      Unmounty snapshotů ve vpsAdminu

      Kdo jste do VPS připojovali snapshot, asi jste si všimli, že často nešel odpojit. Snapshoty do OpenVZ VPS se připojují tak, že se na backuperu snapshot naklonuje přes zfs clone a vytvořený filesystem se exportuje přes NFS. Na nodu se pak mountne do VPS. Při odpojování se nejdříve provede unmount ve VPS a potom se vpsAdmin pokouší odstranit naklonovaný snapshot na backuperu. No a tady to vázne. Z nějakého důvodu je buď mountpoint nebo dataset busy, takže se toho nedá zbavit. To mělo za následek, že operace odpojení snapshotu ve vpsAdminu selhávala a mount se vracel do původního stavu — opět se připojil.

      Na podpoře jsem všem doporučoval mount „vypnout“ (disable), vpsAdmin se ho pak pravidelně snaží odpojovat, až jednou uspěje. Bohužel než se takhle „zaseklý“ dataset umoudří mohlo trvat několik dní nebo i týdnů. Nově se klony snapshotů mažou na pozadí a na mounty ve VPS to nemá vliv. Problémy nám to bude dělat stále, ale aspoň už ty mounty ve vpsAdminu nejsou vidět.

      Zamyšlení na konec

      První commit ve vpsAdminOS vznikl před dvěma lety, 3. listopadu 2017. Asi nikdo nečekal, že s tím bude tolik práce. Pohledem zpět to tehdy ani fungovat nemohlo, hlavně protože až v posledních verzích kernelu se objevují funkce, bez kterých se neobejdeme, à la NFS klient v user namespace. Ani s nejnovějším kernelem, LXC, atd., však bez vlastních úprav nejde dělat systémové kontejnery na úrovni OpenVZ před 10 lety. Menší a větší patche máme v kernelu, ZFS, LXC i LXCFS a nemohli bychom bez nich fungovat.

      Pro provoz OpenVZ jsme naopak dlouho žádné vlastní úpravy nepotřebovali, nebyl problém používat to co bylo k dispozici. Poslední cca 4 roky už se však OpenVZ (Legacy) nevyvíjí a rozjet tam aktuální distribuce je čím dál tím obtížnější. O dnes moderních aplikačních kontejnerech à la docker ani nemluvím. Aby vůbec fungovalo Ubuntu 18.04, museli jsme si připravit vlastní kernel s chybějícím syscallem. Cesta je stále trnitá, ale už se na vpsAdminOS v produkci těšíme.

      Wikiexpedice zamíří do Orlických hor. Za pomoci Wikidat budou dobrovolníci fotografovat pro Wikipedii

      říjen
      25
      wikimedia.cz

      Již čtvrtá česká Wikiexpedice si tentokrát vezme na mušku východní okraj Čech. Fotografové navštíví oblast rozkládající se od Broumova, přes Náchod a Žamberk až po Mohelnici. Cílem je pořizovat obrázky pro sdílené úložiště Wikimedia Commons – především sídla, zahrnuty jsou ale i další objekty, jako například opevnění, přírodní rezervace nebo kulturní památky.

      Expedice navazuje na předchozí úspěšné akce spolku Wikimedia Česká republika, které se uskutečnily ve Slezsku (2016), v západních Čechách (2017) a v jižních Čechách (2018). Během nich bylo pořízeno zhruba 12 800 fotografií příhraničních oblastí České republiky. Akce financuje spolek Wikimedia Česká republika, který hradí cestovní náklady a ubytování. Umožňuje tak dobrovolníkům lépe dosáhnout odlehlejších oblastí, které jsou stranou zájmu a kvůli tomu nejsou na Wikipedii dobře dokumentovány.

      Novinkou je i zapojení Wikidat do přípravy celé akce. Namísto ručního prohledávání jednotlivých článků Wikipedie a hledání objektů, které ještě svůj obrázek nemají, byla činnost svěřena strojům. Wikidata umožňují tyto informace nejen masově zjistit, ale dokonce je vykreslit i do mapy. A to nejen pro vesnice, ale v podstatě pro cokoliv – a tak máme na mapě k dispozici nejen seznam nenafocených vesnic, ale třeba i těžkého opevnění, které mělo bránit republiku v meziválečném období. Na mapě se ukáží všechny sruby a bunkry, které ještě potřebují obrázek.

      Startovním bodem již čtvrté Wikiexpedice bude východočeské město Opočno. Tam se účastníci rozdělí na dva týmy, které budou postupně objíždět fotografované oblasti. Jsou připravené mapy a podkladová data. Tam, kde nebudou tištěné mapy dostatečně podrobné, pomohou účastníkům nástroje jako WikiShootMe nebo mobilní aplikace Wikimedia Commons. Ty také pracují s informacemi z Wikidat. Postup focení na místě potom bude do značné míry odpovídat zažité praxi z projektu Fotíme Česko. Tedy zdokumentovat všechny nepopsané věci, které máme na Wikidatech zaznamenané. S tím rozdílem, že prioritu bude mít osm desítek vesnic, které svůj obrázek nemají. Když se všechno podaří, mohli bychom tak dokončit fotodokumentaci Královéhradeckého a Pardubického kraje.

      SPIR připravil web s informacemi o soukromí na internetu

      SPIR připravil web s informacemi o soukromí na internetu tereza.tumova@… Pá, 10/25/2019 - 08:37

      Zobrazila se vám při návštěvě oblíbené stránky žádost o nastavení úrovně zpracování údajů o vašem chování na internetu? Nerozumíte textům psaným právnickou řečí? Přečtěte si nejčastější otázky a odpovědi a podrobnější informace.

      https://soukrominainternetu.spir.cz

       

      Weekly #77 - UX, Bazel 1.0, Firefox 70, Ubuntu má 15, NordVPN, Ghost 3.0

      říjen
      25
      Fero Volár

      Technológie

      UX & Service design

      Social media & marketing

      Startupy & biznis

      Spoločnosť

      Podujatia

      Kniha týždňa

      Anthony B. Atkinson - Ekonomika nerovnosti

      Weekly #77 - UX, Bazel 1.0, Firefox 70, Ubuntu má 15, NordVPN, Ghost 3.0

      Weekly #77 - UX, Bazel 1.0, Firefox 70, Ubuntu má 15, NordVPN, Ghost 3.0

      Nerovnost je jedním ze současných nejpalčivějších problémů v sociální sféře. Po druhé světové válce se ji dařilo držet na uzdě, ovšem v poslední době se s velkou vehemencí vrací. Všichni o rozsahu tohoto problému vědí, ale jen málo bylo doposud řečeno o tom, co se dá dělat, když si nechceme jen zoufat. Podle uznávaného ekonoma Anthony Atkinsona je možné nerovnosti čelit mnohem více, než si skeptikové dokážou představit. Atkinson je již dlouho jedním z čelních představitelů výzkumu nerovnosti a do řešení různorodých problémů, které se nerovnosti týkají, vkládá veškeré své teoretické i praktické zkušenosti. Nyní představuje široký soubor opatření, která mohou skutečně způsobit změnu v distribuci příjmů ve vyspělých zemích. Jak Atkinson ukazuje, problémem není pouze to, že se bohatí stávají stále bohatšími. Nedaří se nám vypořádat se s chudobou a celá ekonomika se mění takovým způsobem, že většina lidí v ní ztrácí. Chceme-li snížit nerovnost, nesmíme se spokojit s pouhým ukládáním nových daní bohatým lidem, jimiž budou financovány stávající programy. Potřebujeme nové nápady. Proto Atkinson doporučuje ambiciózní opatření v pěti oblastech: technologie, zaměstnanosti, sociálního zabezpečení, sdílení kapitálu a zdanění. Vyvrací běžné argumenty a výmluvy, jimiž se omlouvá nečinnosti: že by zásah způsobil pokles ekonomiky, že globalizace znemožňuje udělat s nerovností cokoliv a že si nemůžeme dovolit zavést nová opatření.

      Sleduj ma na goodreads.com/FeroVolar

      Internetová populace ČR dosáhla v září 7,8 milionu uživatelů, výhradně z mobilních zařízeních se připojilo téměř 900 tisíc osob

      Internetová populace ČR dosáhla v září 7,8 milionu uživatelů, výhradně z mobilních zařízeních se připojilo téměř 900 tisíc osob tereza.tumova@… Čt, 10/24/2019 - 06:08
      Tisková zpráva

      Praha, 24. října 2019 – Internetová populace ČR starší deseti let dosáhla v září 7,8 milionů osob, 5,3 milionu uživatelů se k internetu připojilo z mobilního zařízení (telefon nebo tablet), přičemž výhradně na mobilních zařízeních surfuje 899 tisíc osob. Hodnota programatiku byla v září 620 milionu Kč v ceníkových cenách a jeho podíl na celé displejové reklamě představuje 52 %. Data vyplývají z aktuálních výsledků projektu NetMonitor a AdMonitoring, které připravuje Sdružení pro internetový rozvoj (SPIR).

       „Vidíme konstantní přímý růst části internetové populace, která přistupuje k internetu přes mobilní zařízení, což jsou telefony nebo tablety. V září to bylo 5,272 milionu lidí a z nich se připojuje výhradně přes mobilní zařízení 899 tisíc uživatelů. Tento trend nárůstu sledujeme již několikátý rok a je zcela přirozený, jak se zdokonalují technologie koncových zařízení, zvyšuje počet míst pokrytých internetem a postupně dospívá generace, pro kterou je mobil v ruce a neustálé připojení něco zcela přirozeného,“ komentovala výsledky Kateřina Hrubešová, výkonná ředitelka Sdružení pro internetový rozvoj (SPIR).

      V projektu NetMonitor bylo v září zapojeno 528 měřených serverů, na kterých uživatelé z ČR a zahraničí zhlédli 6,8 mld. stránek. Zářijové výsledky projektu AdMonitoring ukazují, že se vrátil meziroční růst direct display reklamy, který byl v září 2019 o 6,4 % vyšší než rok předcházející a dosáhl objemu 576 milionu Kč v ceníkových cenách. Od ledna 2019 jsou v AdMonitoringu nově k dispozici výsledky výkonu programaticky obchodované displejové reklamy. Ty ukazují, že programatik dosahuje většího objemu než klasicky obchodovaná displejová reklama. V září měl programaticky obchodovaný displej hodnotu 620 milionu Kč v ceníkových cenách, což představovalo 52 % z celkového objemu displejové online reklamy zachycené v rámci AdMonitoringu. 

      Kompletní výsledky kvartální prezentace naleznete níže v příloze pod článkem.

      graf1

      Zdroj: NetMonitor – SPIR - Gemius, leden 2008 – září 2019

      graf2

      Zdroj: AdMonitoring – SPIR/Nielsen Admosphere, leden 2017 – září 2019, ceníkové ceny, výkon zapojených médií

      Nepoužívám žádnou VPN pro bezpečnost nebo anonymitu

      říjen
      22
      Michal Spacek
      NordVPN: Ain't no hacker can steal your online life. \(If you use VPN). keksec: This one isn't our work, its just been floating around mostly unnoticed. Plus a link to some private keys and more.

      Tweet od keksec, ve kterém incident oznamují širšímu publiku

      Nepoužívám žádnou VPNku pro bezpečnost. Dokonce nepoužívám žádnou VPN ani pro anonymitu. Tu stejně poskytovatelé VPN nedokáží zaručit, takový poskytovatel VPN je jenom další poskytovatel připojení k Internetu (Internet Service Provider, ISP). Na pár „vépéenek“ jsem se díval zblízka a můžu celkem v klidu říci, že trh s VPN se proměnil v minové pole s rádoby anonymními vedoucími společnostmi, s rozšířeními prohlížečů, z nichž některé uživatele jen přesměrují na weby s reklamou, zatímco jiné pro jistotu přenášená data nešifrují vůbec.

      Dělám ale něco jiného. Snažím se tlačit weby k přechodu na HTTPS a k implementaci věcí jako např. HSTS – HTTP Strict Transport Security (to řekne browseru, že má požadavky automaticky upgradovat na https:// i když kliknete na odkaz začínající na http:// nebo když do browseru to https:// nenapíšete protože proč byste to dělali), takže zabezpečení se zvýší každému návštěvníkovi. Tlačím na služby, aby přešly na šifrované protokoly a nešifrované varianty ani nenabízely – líbí se mi jak to dělá např. Gmail a fakt mi vadí místní velcí hráči, kteří nabízí nešifrované poštovní protokoly (ale tak aspoň napíšou, že to není doporučované). Na webech, které nemají HTTPS nic nekupuju.

      Ale aby se neřeklo, tak nějakého VPN poskytovatele používám – k obcházení různých hloupých geo omezení, pro porovnání cen při přístupu z různých zemí, pro hledání divných věcí na gůglu, protože nechci, aby ostatní zařízení na mé síti viděla kapču, protože zrovinka já se snažím hledat věci, které hledají i různí roboti. Ale nepoužívám VPN na to, abych byl „safe online“.

      Pro lepší zabezpečení vašich prohlížečů si nainstalujte extenzi HTTPS Everywhere od EFF, díky které bude váš browser na HTTPS „auto-upgradovat“ ještě víc webů. Ale na to, abyste byli „safe online“ na veřejných sítích (jako např. Internet) žádnou VPN-as-a-service nepotřebujete. A jen teda pro úplnost, tohle je o VPN službách pro koncové uživatele, ne o nějakých ciscách pro firmy apod.

      Před několika lety jsem nějaké poskytovatele VPN služeb doporučoval, ale už to nedělám. Web (a celý Internet) se posunul kupředu a HTTPS používá čím dál tím víc webů 🎉 Takhle to vypadá v grafu za poslední tři roky:

      Nov 2, 2016: USA users 57.76291%, All users 48.55465%, Japan users 24.53105%; Oct 8, 2019: USA users 89.36207%, Japan users 80.20807%, All users 79.97562%

      Procento stránek načtených Firefoxem pomocí HTTPS (zdroj, podobná data z Chrome)

      Samozřejmě, můžu si postavit vlastní VPN server pomocí nástrojů jako Algo nebo Streisand a být tak poskytovatelem sám sobě, ale to by pro mě znamenalo mít další separátní stroj na zabezpečování a to už raději budu otravovat ostatní, aby si zabezpečili ty svoje 😜

      Vlastní VPN server pro vás taky vůbec nemusí být to nejlepší možné řešení, protože v takovém případě váš síťový provoz nebude pocházet od vás, ale z vašeho serveru (a jenom z vašeho serveru a jenom váš provoz, vidíte ten drobný problém?) Samozřejmě to všechno záleží na tom co děláte a potřebujete. Ale pro nějaké zabezpečení a online anonymitu žádnou VPN službu nepoužívejte. Zkuste raději Tor Browser, ale pozor na to, že takové anonymní surfování je docela oříšek, zvlášť z dlouhodobého hlediska, takže možná bude lepší, když se do situací, které anonymitu vyžadují vůbec nedostanete, jo?