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

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

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

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

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

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