Month: April 2018

На 14.04 посетих конференцията на Bulgaria Web Summit 2018. Това беше и първото ми посещение на подобно събитие. Разбрах за него от колегата Кирил, проверих темите на сайта http://bulgariawebsummit.com/ и набелязах доста интересни теми. Проблемът беше, че по едно и също време щяха да се провеждат 4 различни лекции. Изборът не беше лесен, но нямахме право на глас :).

Денят започна лекцията на Светлин Наков на тема “Blockchain Cryptography for Developers“.  Беше доста технически ориентирана. Ставаше въпрос за:  елиптични криви, secp251k1 (кривата на Bitcoin), цифрови подписи, генериране на Ethereum адреси, подписване на транзакция в Ethereum, хеширане, SHA256, SHA3, keccak256, HMAC, извличане на ключ по парола, шифриране на данни, AES, SCrypt, крипто-портфейли и някои стандарти около тях като BIP39 и BIP44. Беше полезно, но имаше твърде много информация на кратко време.

Втората лекция, която посетих беше “Building scalable web apps for patients” с водещ Красимир Цонев. За съжаление не можах да остана до края, тъй като имаше много хора и не се чуваше добре в края на залата. Темата беше интересна и доста популярна в последно време – софтуер за връзката между пациент и лекар или т.нар. дигитално здравеопазване.

Третата и със сигурност най-интересна за мен лекция беше на тема “Simplicity is not Simple.” на Dave Hogue. Тя беше интересна по няколко причини – водещият грабна аудиторията с ораторските си умения, презентацията беше изключително добре подготвена, темата е изключително наболяла в днешния свят на дигитализиране. Стана въпрос за това, че твърде лесно на вид и най-простият софтуер, разполагащ с най-малко функционалности може да стане излишно сложен. Накара всички ни да се замислим върху какви проекти работим ежедневно, как можем да ги подобрим и най-вече защо. Само заради тази лекция си струваше цялото събитие (лично мнение) :).

Четвъртата лекция беше “React Native App: Expectations vs Reality.” на Калоян Косев. Той ни разказа за неговия опит с набиращата все повече популярност работна рамка за нативни приложения React Native. Имаше няколко основни точки в неговата презентация, които ми се набиха:

– трябва да имаш предишен опит с ReactJS, за да преминеш на     React Nativе в противен случай, би отнело доста време докато свикнеш с технологията.

– няма почти никакви плъгини и разширения за React Native

– дебъгването е трудно

– производителността е изключително добра.

В крайна сметка не успя да ме убеди, че трябва да пробвам да науча и да се занимавам с React Native.

Следващата лекция беше на тема “The next evolution of the Web” с водещ Биляна Вачева. Тя разказа на навлизането на т. нар. виртуална реалност в съвременните уеб технологии. Показа ни, че тя ще се използва не само за забавление, както до момента. Разказа ни за новите тенденции при разположението на елементите на една уеб страница в режим на виртуална реалност.

Шестата лекция също беше интересна “There is a lot of buzz around the progressive framework named VueJS. But why is it truly special and interesting?” с водещ Roman Kuba. Той ни разказа за новата работна рамка за JavaScript – VueJS. Изключително интересна технология, която бихме могли да имплементираме в PMS4 някой ден :).

Предпоследната лекция беше за ревюта на кода “Practical code reviews” с водещ Илко Качаров. Имаше полезни съвети, но нищо което и преди не сме чували за ревютата на код.

Последната лекция “Storing Data in MongoDB” беше с автора на Xdebug и старши софтуерен инженер в екипа, разработващ MongoDB – Derick Rethans. Интересна лекция за това как се работи с нералационната база от данни на MongoDB. Показа ни основните концепции при дизайна на базата данни в зависимост от нуждите на софтуера, който разработваме. Наред със силните страни на използването ѝ ни показа и нейните слабости, което беше доста интересно.

Като цяло бих определил посещението си на конференцията като много ползотворно. Научих нови неща, успях да добия представа за новите тенденции в уеб технологиите, запознах се с интересни хора, спечелих тениска :).

Нещо друго, което ми направи впечатление е, че чуждите лектори бяха по-добри от нашите. Жалко, но факт!

В събота посетих 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
Лекцията беше изградена на базата на аналогия на даден проект, по който работим,  с къщата, в която живеем. И както всеки иска къщата му да бъде подредена и чиста, така трябва да се стремим и кода, който пишем да бъде чист и подреден.

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

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

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

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

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