В събота посетих Bulgaria Web Summit 2018 за първи път. Лекциите бяха разпределени в 4 зали на ралични етажи, което значеше, че само 1/4 от тях можеха да бъдат посетени. Това което не ми хареса е, че между отделните лекци не беше предвидено време за за почивка и смяна на залата поради което се получаваше суматоха около края и началото на лекциите.

Първата лекция, което посетих беше How to hack a node app на Asim Hussain от codecraft.tv. И преди съм попадал на негови статии свързани с javascript и Angular. Доста забавно беше представен сериозен проблем със сигурността на повечето уеб проекти. Бяха дадени за примери популярни сайтове станали известни с изтичането на огромен обем лични данни на потребители. А причината за това са дребни на пръв поглед пропуски в сигурността, ненаправени ъпдейти на наличния софтуер, които като се навържат може да се стигне до пълен контрол над системите. Също така се обърна внимание на занижения контрол над библиотеките, които се разпространяват свободно през портали като npm, composer и др. В тях могат да попаднат библиотеки със злонамерен код, имитиращи популярни такива и човек ако не внимава може лесно да се подведе. Основните изводи от лекцията са – контрол над кода, който се използва в нашите проекти, актуални версии и ъпдейт на софтуера.

Следващата лекция беше Sharing code between web and native apps на Sebastian Witalec. Авторът е от екипа разработчици на NativeScript – технология, чрез която могат да бъдат създавани напълно native мобилни приложения пишейки единствено javascript код и използвайки изгледите на съответната платформа – iOS или Android. В лекцията се обърна внимание на възможността да се създаде Angular проект, в който кодът да е един и същ, но да се използват различни модули и изгледи за отделните платформи – за уеб, iOS и Android. За целта уеб версията се компилира от стандартния angular cli tool, а останалите – през native script cli tool. Споменато беше и очаквано съвсем скоро интегриранe на native script cli tool в angular, което още повече ще улесни интеграцията. Беше направено и демо, показващо един и същи проект на трите платформи. Лекторът също така обърна внимание на възможни проблеми и техните решения. Като цяло много полезна лекция за angular и native мобилни приложения.

Третата лекция, което посетих беше Building decentralized apps на Emil Stoyanov. Ставаше дума за приложения използващи world computer в blockchain-а на ethereum като платформа. Имаше доста терминология, с която не бях запознат и ми беше трудно да разбера някои от аспектите. Но все пак лекторът представи с какви предизвикателства се е сблъсквал при разработката на такива приложения, плюсовете и минусите на този подход.

След обедната почивка посетих лекцията React native app: expectations vs reality на Kaloyan Kosev, който разказа за своя опит при създаването на native мобилно приложение, използвайки react native – технология подобна на native script, разработена от facebook и надграждаща техния reactjs. Впечатленията си беше подредил в няколко категории – learning curve, limitations, debugging, ecosystem, performance. Като цяло очакванията му са били по-големи от реалността. Времето за научаване е било значително дори и за опитен reactjs разработчик поради слаба документация, не голяма популярност и съответно липса на информация при възможни проблеми. Ограниченията на платформата са разбираеми с оглед на това, че не е native платформата за разработка, но все пак за зависели от избора на фреймуърк – expo или react native app. Лекторър беше силно разочарован от възможностите за дебъгване на приложенията. Наличните библиотеки и готови компоненти също са били малко и не добре поддържани. Единствено производителността е отговорила на очакванията му – не се усеща разлика от native приложение. Слайдове

Лекцията Beyond documentation with OpenAPI на Boyan Yordanov ми беше наистина интересна – описваше решение на основен проблем при разработката на API – писане на документация, трудната поддръжка и несъответствие с кода. Решението е писането спецификация/схема на апито, която да се използва за документация и тестове удостоверяващи правилните данни. Споменати бяха различни стандарти като API Blueprint, RAML, JSON Schema,но беше обърнато внимание на предимствата на OpenAPI initiative (преди Swagger). Схемата се пише във формат yaml или json. Разработва се активно и има голяма популярност, поради което има много инструменти, с които се генерира документация, интегрира се лесно в тестове за различни езици, създават се автоматично gui-та за примери, интеграция в редактори. Представени бяха и различните възможности на спецификацията при описването на пътищата и параметрите, интегриране на JSON Schema.

Следващата лекция беше отново на javascript тематика – There is a lot of buzz around the progressive framework named VueJS, представена от Roman Kuba. Много добра интродукция за VueJS – javascript framework, който в последно време настига по популярност React.js и Angular. Лекторът нагледно показа защо се нарича progressive framework – можеш да започнеш да го използваш много лесно за елементарни неща – data binding, templating и т.н. и да надградиш към доста по-сложни концепции. Наистина удобен и интуитивен за ползване framework. Гледната точка на лектора беше обективна – той е бил част от решението да заменят angularjs с vuejs в интерфейса на codeship – популярна платформа за continuous integration, където работят с голямо натоварване и производителността на интерфейса е от голямо значение. Слайдове

Лекцията Testing against time in javascript applications на Jessica Jordan ми беше малко трудно да проследя поради особеностите на говора на лектора – много бързо, монотонно и слято. Все пак представи различни техники за тестването на асинхронни операции при писането на unit test-ове в Emberjs. Въпреки, че примерите използваха тестови рамки за Emberjs, концепцията е валидна и за останалите. Използваха се таймаути, мокване на заявки, callbacks.

Working the right way by knowing all the wrong ways на Boyan Djumakov беше последната лекция, която посетих. За жалост времето беше съкратено и крайно недостатъчно поради продължителността на предишната лекция в същата зала. В резюме бяха представени лоши практики в работния процес на разработката на софтуер както и съвети и решения за по-висока продуктивност, по-добра комуникация и успешни проекти. Важни изводи от лекцията – грешки винаги ще се правят, не трябва да се прикриват. Важно е да се споделят дори неуспехите и затрудненията. Временните компромиси почти винаги излизат скъпо след време. Ако не си в състояние да работиш ефективно – по-добре си почини. Обръщай внимание на комуникативните си умения, ефективното търсене на решения. Винаги някой ще знае повече от теб – търси помощ, не прави всичко от нулата. Не обещавай сляпо, бъди отговорен. Не следвай сляпо модата (инструменти, рамки, езици). И много други съвети, които са описани добре в слайдовете

Тази година за първи път реших да посетя Bulgaria Web Summit – конференция за Front-end, Back-end, UX, Design и не само. За нея чух от колеги. Посетих сайта на събитието и се запознах  с програмата. Звучеше многообещаващо – 4 зали, много лектори, интересни теми от различни сфери.
Лекциите във всяка зала започваха по едно и също време и се препокриваха, така че предварително си бях набелязала, кои бих искала да посетя. Бях си подготвила и печатна версия на програмата(за съжаление такава не беше публикувана на сайта на събитието), за да мога на място бързо да сменя някоя лекция.
За целият ден посетих общо 8 лекции. Тук ще спомена само някои от тях.

How to hack a node app?
Asim Hussain
Минути преди първата лекция бях на място, готова да чуя как се ‘хаква’ node приложение. Лекторът ни запозна, с някои от известните хакерски атаки от последните години, как точно са извършени, какви слаби места на софтуера са използвани и по какъв начин.
Изводите накрая бяха:
– Не се доверявай на никого – филтрирай клиентските данни;
– Не подценявай и дребните, на пръв поглед, места за пробив. Когато ги откриеш – просто ги поправи.
– Ако не си сигурен в името на пакета, който искаш да инсталираш – не налучквай, а провери в официалните източници. Иначе сам можеш да поканиш ‘врага’ на гости.
Въпреки, че очаквах по-практическа насочена лекция с повече примери и техники за писане на сигурен код, като цяло  ми хареса.

Sharing Code Between Web and Native Apps
Sebastian Witalec
С много примери и в реално време лекторът ни запозна с начините за споделяне на код между приложения за различни устройства/операционни системи, използвайки общо хранилище за съхранение на кода; MVC (Model, View, Component) модела за разделяне на приложението на пластове и споделяне на общите части;  namespace за дефиниране и обработка на разликите. Показа ни и инструменти за преобразуване/прекомпилиране на съществуващи решения в такива със споделен код.

Simplicity is not Simple
Dave Hogue
Една от най-интересните лекции, които посетих. Стана дума за това, че в повечето случаи, започвайки един проект, човек е с едни очаквания за сложност и функционалност, а в процеса на разработка, постепенно се откриват нови изисквания и възникват нови идеи, които усложняват крайния продукт. И въпреки, че той е завършен и доставен, това не винаги означава, че е постигната първоначалната цел, ако реално е трудно да се работи с този продукт и крайният потребител не е доволен.
Много често след разработката на последните изисквания, работата по проекта не е завършена, а се налага връщане назад и преоценка на системата с цел подобряването и опростяването на потребителския интерфейс.

По интересен и увлекателен начин ни бяха представени видовете системи: прости(simple), сложни(complicated), много съставни(complex), хаотични(chaotic).

Тъй като хаотичните системи са непредсказуеми и не подлежат на опростяване, в лекцията бяха засегнати сложните и многосъставни такива.
Това са системи с много функционалности, много процеси, натоварен потребителски интерфейс. Такива системи са трудни за използване и управление. Понякога системите са по природа сложни и не може да се опростят, но не винаги е така.

Признаци за възможност за опростяване:
– неинтуитивни и объркани последователности в действията;
– ‘индиректни’ действия – т.е за да постигнеш нещо на текущата страница трябва да извършиш действие на друга страница;
– опит за доставяне на всичко на всеки – добавяне на функционалности без да са реално необходими, само за случай, че потрябват;
– добавяне на функционалности, само защото някой  е казал, че е ‘хубаво’ да ги има;
– копиране на чужди идеи – да направим нещо, само защото и другите го правят. Това, че го правят не означава, че е непременно правилно :);
– следване на съвременни методи и технологии, без да са реално необходими.

След като ни запозна с начините на идентифициране на необходимостта от опростяване, Dave Hogue ни запозна и с методите за опростяване:
– премахване на ненужни функционалности;
– комбиниране на два по-малки модула в един общ;
– приоритизиране – поставяне на фокус върху една основна функционалност за дадена страница;
– разделяне на сложна функционалност на две по-прости.
Като цяло беше наблегнато на това, че целта на даден проект трябва да бъде не само успешното му завършване, но и постигането на добър потребителски интерфейс, което е итеративен процес, който се постига на няколко цикъла и е важна част от разработката на даден продукт/система.

Code Review
Ilko Kacharov
Лекцията беше изградена на базата на аналогия на даден проект, по който работим,  с къщата, в която живеем. И както всеки иска къщата му да бъде подредена и чиста, така трябва да се стремим и кода, който пишем да бъде чист и подреден.

Както във всяка къща има установени правила от домакина и трябва да се спазват от всички в къщата, така и всеки, който се присъедини към даден проект, трябва да бъде запознат с правилата на работа и да ги спазва. Човекът или хората, които правят ревю на кода са всъщност домакините. Те проверяват дали са спазени правилата и ако не са  – сигнализират за това съответния разработчик. По този начин се постига прозрачност.

Ревюто се прави обикновено от по-опитни участници в проекта. Добра практика е да се прави често – при всяко качване на код в хранилището. Така ръководните членове на екипа имат поглед върху извършваната в момента работа, както и това дава възможност за намаляване на риска от загуба на излишно време за преработка на код, писан няколко дни.

Основните неща, споменати за важни при код ревю:
– проверка за повтарящ се код;
– проверка за повтаряща се функционалност;
– бъгове и неконсистентност;
– проверка на зависимости между библиотеки;
– бързодействие;
– лесна поддръжка.

Беше наблегнато на това, че ревюто на код е социален процес. Дава възможност за бърза обратна връзка. Ако тя е положителна – това води до стимулиране на съответния разработчик.
Важно е да не се губи фокус – оценката трябва да е насочена към написаният код, а не към разработчика.
Коментарите трябва да бъдат издържани в стила на добрия тон:
– да се използват предложения вместо заповедни изречения;
– да се задават въпроси;
– да се използват учтиви форми – моля;
– да се използват похвали;
– предложенията трябва да са на последно място.

Въпреки, че имаше и добри лекции, като цяло очаквах малко повече.
Самата организация, също може да се подобри. Хубаво е да има интервал между лекциите, за да може човек да се премести от една зала в друга. На моменти залите бяха препълнени и нямаше място за всички. В някои зали нямаше микрофон и на последните редове се чуваше много слабо.