Bulgaria Web Summit 2018

On 14th April, 2018 me and my colleagues attended the Bulgaria Web Summit event, which was held in Inter Expo Center Sofia. It was the first time I ever attended such event, so I didn’t know what to expect. I was pleasantly surprised with the good organisation and the great variety of activities the event offered. In the website of the event there were timetable for all 32 lectures, which were going to be presented throughout the day. Unfortunately there were only 8 time slots and each four lectures were held in the same time in one of the 4 rooms provided, therefore, we had to choose the lectures that were most attractive and most useful to each one of us and visit only them.

Having seen the timetable in advance, I was prepared with a list with the timings and rooms of all the lectures I wanted to attend, as well as some additional ones, in case the room capacity was not enough to fit all who were interested.

The first lecture I attended was “How to hack a mobile app?”. The lecturer Asim Hussain talked about the kind of weak spots hackers look for in all apps in general. The main point was that real security issues do not come from the big holes in security, but from the small ones, that we often neglect. Not escaping html for example, puts our web sites in risk of SQL injection. Example for this is Company House based in the UK, where you can register your company, without your information being protected. Hackers often rely on users` or programmers` distraction as in the case of open source projects, which are believed to be trustworthy and safe, but often are easy target for hackers. They use the same name with dot (.) or remove slash from it, therefore making it hard to notice at first glance. In this way one could download libraries with malicious code instead of the desired open source project. The last, but not least that I learned from this lecture was how important it is to keep all your software and packages up to date, since programmers constantly improve their products’ security.

The second lecture on my list was about Building Scalable Web Apps For Patients” by Krasimir Tsonev. He talked about the company he works for and their aim to help people. It is a digital health company, which mission is bridging the gap between medical research and the people who need it. Their “clients” are often people who are incurably ill and have no time. The major point he made was that such people are tired from waiting and searching for what they need, so the company aims to provide web apps that are scalable and adjust to the users’ needs. They study their patients needs daily and create profiles for them, thus allowing the delivery of valuable information only and avoiding unnecessary questions and adds.

The lecture that I found most interesting was “Simplicity is not Simple”. The lecturer was Dave Hogue, who works as Psychologist and UX Lead at Google. He was very enthusiastic and made it obvious that he takes the subject seriously. He told us, it is easy to make everything complicated, but the reverse process takes a lot more time and efforts. The main point was that one needs to think before they act. If you take the time to plan and decide what you really need to have in your app, you will not add anything unnecessary. Common mistakes are adding functionalities only to check if user would use it, to search similar websites and to take everything, nonetheless, you might not really need it. When you start to think whether something is good to have as functionality, but then you find something that is even better and better you end up in a mess of functionalities, most of which do not even have place in your project. Hence, it is crucial to find the balance between adding all necessary functions and keeping it simple in the same time. All in all, the essence of that lecture perfectly summarizes in a quote by Albert Einstein that states “ Everything should be made as simple as possible, but not simpler.”

Following the afore discussed lectures, we all had a lunch break, after which I continued my day with “Art of noise” given by Léonie Watson. She talked about the evolution of voice technologies over the years. There were examples of computer voice sounds from 1992 and current modern technologies. Nowadays, voice interaction is very common. People often use it to communicate with and control their phone or other connected home devices. However, while some of us use voice technologies just for fun or convenience, for others they are necessity that helps them go through everyday tasks. Voice technologies’ development strives for better interaction with human beings, therefore aiming to improve punctuation accuracy, clarity of speech and similarity to human speech. What is even more impressive, is the possibility of integrating voice recognition and other voice technologies into artificial intelligence.

Following the “Art of noise” I continued with “The next evolution of the Web” presented by Bilyana Vacheva. She talked about upcoming Virtual Reality Browsers which allow you to see and navigate through web pages via VR glasses. This type of browsers are still developing, but there are already some initial versions created. The idea behind this evolutionary technology is that VR glasses could be used in jobs such as web developing instead of for fun only. For this purpose, new generation browsers need to be more coordinated. However, when talking about getting a job done via VR browser, one should feel confident about what they press and when, while in games this is not of great importance, since the major purpose is to have fun. My personal opinion, about such use of VR browsers is that it will not be applicable, due to the long duration of sessions and the fact that a person doing this is expected to wear the glasses for up to 6-8 hours a day, which I believe will be very uncomfortable and difficult to achieve no matter how isolated one is from external distractions.

The last lecture I attended was “Working the right way by knowing all the wrong ways” by Boyan Djumakov. He talked about bad practices, teamwork, self improvement, and helping each other to improve self knowledge and self confidence. Unfortunately, he could not finish his lecture because of the time, but the way I see it the essence of the lecture was that one should not feed their ego, but their knowledge and respect the people who they work with. Another aspect, he came across with, was work laziness and how employees need to find the way to go over it and do the job they are being paid for and learn to be proud of their goals and achievements.

There were another two lecturers that I attended, however I did not find them as interesting as expected. Overall, I was impressed with the event and I got to learn many interesting things and familiarize with new innovations and technologies. As unfortunate as it is, I was more impressed by the foreign lecture presenters and believe they master presentation skills, that the Bulgarian ones lacked. The foreigners, whose lectures I attended, were able to better express themselves without using too sophisticated language or inappropriate words, as some of the Bulgarians did. Moreover, some of the bulgarian presenters spent a lot more time than needed, on side issues that had nothing in common with the lecture, which was uncalled for. Even though, some lectures overlapped I still think in general the organization of the event was very good. It was nice there was a variety of interesting lectures, as well as number of different innovations that were exposed in the lobby, where everyone could see them and ask questions about.

Bulgaria Web Summit 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. Показа ни основните концепции при дизайна на базата данни в зависимост от нуждите на софтуера, който разработваме. Наред със силните страни на използването ѝ ни показа и нейните слабости, което беше доста интересно.

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

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

The Mythical Man Month

Една от класиките сред книгите за управление на софтуерни проекти. Написана преди повече от 40год., много от тезите са валидни и днес, което е и причината за преиздаването ѝ след толкова време.

Описват се основни възприятия в процеса на разработка, върху които малко хора са се замисляли и осмисляли – като защо обичаме да програмираме, какви са негативните страни от това, защо не успяваме да прогнозираме добре необходимото време за разработка. Някои от причините за последното са това, че сме оптимисти, не включваме в преценката си времето за комуникация, за дебъгване и тестове. Съществува също така грешното схващане, че работата на един разработчик е константа като човекочас. Съответно при забавяне в разработката на проект най-лесното решение е да се добавят още хора. Пропуска се обаче, че това внася допълнително натоварване към останалите и изисква повече време докато екипът се сработи. От тук произлиза и изводът, станал известен като закон на Brooks – “Adding manpower to a late software project makes it later”.

Друга интересна концепция, която се развива в книгата е начин за управление на разработката на голям софтуерен проект от голям екип разработчици (100+). Представят се предизвикателствата пред ефективното управление на много хора и един подход, който може да помогне – създаването на малки “хирургични екипи”. Малките екипи се състоят от един основен разработчик – “хирургът”, който взима решенията и разработва най-важните части от софтуера. Около него се създава екип от поддържащи роли – “копилот”, който може да върши всичко, но е с по-малък опит; “администратор”, който се занимава с административните дейности; “редактор” – документацията; двама “секретари” помагащи на администратора и редактора; “чиновник”, “инструменталист”, “тестер”, “адвокат на езика”, който познава тънкостите на използвания език за програмиране. По този начин комуникацията се разделя по определени роли и се улеснява скалирането на екипите.

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

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

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

Bulgaria Web Summit 2018

В събота посетих 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 2018

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

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

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

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

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

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

PMI-PBA Certification

Преди два месеца започнах подготовка за изпит за сертификат за бизнес анализатор – PMI-PBA и в настоящата статия ще споделя мнението си за книгите и материалите, които използвах.

В мрежата има много информация относно процеса за кандидатстване (попълване на формуляра, изисквания за допускане до изпит, проверка на кандидатите), препоръки за курсове и учебни материали, трикове за по-лесно запомняне и успешно попълване на теста. Обемът информация, върху който е изграден изпита е доста голям. Самият PMI има изготвен списък от 12 книги за прочит. Препоръчват се различни курсове, семинари и книги по темата.

За своята подготовка аз избрах:

1. Онлайн курс – iZenBridge – PMI-PBA Exam Prep Course.

За този курс разбрах от един форум. Оказа се доста добър и полезен. Изготвен е специално за успешното вземане на PMI-PBA сертификата.

Съдържа повече от 60 часа лекции, групирани в няколко раздела. Има както въвеждащи, така и подробни лекции по различните теми. На по-важните теми има отделни лекции.

Информацията е поднесена по добър начин и на разбираем език. На моменти качеството на видеата не е много добро, но това не пречи на възприятието.

На края на всеки раздел има примерен тест от 10 въпроса за проверка на придобитите знания. Отделно има достъп до примерни тестове с по 50 въпроса от всяка област, както и 2 примерни теста от по 200 въпроса. Хубавото на тестовете е, че след попълване може да прегледаш отговорите и към всеки въпрос има допълнителна информация за отделните опции и анализ на верния отговор.

Включени са и видея с разяснителни семинари.

Курсът е достъпен в рамките на 90 дни. Регистрацията дава достъп до форум и възможност за задаване на въпроси, както и участие в различни семинари.

В курса е препоръчана следната книга:

2. Business Analysis for Practitioners: A Practice Guide

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

3. PMI-PBA Certification Study Guide.

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

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

Започва със съкратен преглед на съдържанието на изпита, последван от по-подробно описание на всяка една от 5-те области от знания, които ще бъдат тествани. Информацията е кратка, без подробности. Едно и също съдържание се повтаря в различна форма – текст, таблица, диаграма. Важната информация е маркирана, за бърз преглед в последствие и по-лесно запомняне. Има много препратки към PMBOK като източник на информацията.

Книгата съдържа различни упражнения за затвърждаване на знанията – въпросници, кръстословици, таблици със скрити думи. Всеки раздел завършва с примерен тест. В края на книгата има примерен тест от 100 въпроса.

Според мен, информацията в книгата не е достатъчна. За придобиване на необходимите знания трябва да се търсят допълнителни източници.

4. PMI-PBA® 200-Question Sample Exam.

Тази книга също е една от най-препоръчваните за придобиване на представа какво представлява самият изпит. В сравнение с онлайн тестовете, включени е курса обаче, не е особено добра. Половината книга е тест от 200 въпроса, с другата половина – същият тест с отговори. Това, което не ми харесва е, че няма никакви обяснения на понятията, в сравнение с онлайн тестовете от курса, на пример. Има препратки за информация към външни източници – тези от списъка на PMI.

 

Bringing multiple Virtual Hosts within the same URL space with Apache

Our team has been working on a rather large and complex web application project for the past couple of years. Now, nearing its completion, we are challenged with the necessity to host, deploy and support the ready product. On one hand side, we want to retain control over the code base for each customer separately, i.e. be able to introduce individual installations which coexist but have different source code versions. On the other side, we want to offer the platform to everyone under a common URL namespace and be sure, that every user is routed to their own virtual host.

Main Challenges

  • Host a large number of virtual hosts (e.g. more than 1000), each with its own code base, source code revision, database and settings;
  • Introduce individual customer identification and authorization;
  • Secure the virtual hosts serving the actual application and isolate them from the outside World through a firewall;
  • Use the above information to route each customer to the correct virtual host, representing their individual installation;
  • Bring everything transparently under the same URL namespace, advertising a single URL to everyone for product access.

The Approach

The basic idea was to authenticate each web user for the purposes of giving them access to the application. Then use this information to route the user’s requests to the correct virtual host, that contains their individual code base and settings. To achieve this, we decided to introduce a gateway server to handle the authentication and routing.

Continue reading “Bringing multiple Virtual Hosts within the same URL space with Apache”

SVN + SSH Access Log to GrayLog

Log SVN Access to a Central Location

Today I was searching the web for ways to log access to our Subversion repositories. It turns out, that there is no built-in straightforward way to do that. Most of the posts on the Web suggest using the Apache’s access log. This could work only if you have set-up WebDAV on your Apache server. We prefer to use SSH tunnels to access our repositories for many reasons, overhead being one of them.

So I took another run and ended up reading Kintoandar’s blog. He explains a rather simple way of making SVN log every access to the repository. It is based on svnserve, which is called every time a connection to the repository is made. The command itself supports logging, but the optional parameter for using log files is rarely used. Continue reading “SVN + SSH Access Log to GrayLog”

Курс по английски в Лингуа Мунди

Преди по-малко от месец завърших успешно ниво Upper Intermediate (B2) в школата “Лингуа Мунди” гр. Пловдив. Впечатленията ми от курса са положителни, но да разкажа и малко по-подробно за плюсовете и минусите:

Нещата, които ми харесаха:

  • преподавателката говореше само на английски език.
  • учебниците са по нови системи за обучение с много упражнение с говорене.
  • граматиката е ясно обособена и добре поднесена.
  • изцяло интерактивнa е учебната стая: прожектор, touchscreen дъска, видеа, компакт дискове с уроците.

Нещата, които можеше и да са по-добре:

  • тестовете са прекалено лесни с цел да няма пречки да запишеш следващото ниво.
  • неудобни са часовете на курсовете за сертификати (Cambridge, TOEFL, IELTS, etc).

Като цяло препоръчвам школата заради учителския състав, методите на обучение и отношението им!

Continue reading “Курс по английски в Лингуа Мунди”

Modernizing Legacy Applications In PHP

Modernizing Legacy Applications In PHP

Тази книга описва необходимите стъпки за модернизирането на остаряло приложение. Дава добро описание на понятието “legacy”, както и защо трябва да бъде модернизирано. Самите стъпки са добре подбрани, макар че ми се искаше примерното приложение в книгата да придобие още по-завършен вид. В крайна сметка крайният резултат доста наподобява това, което представляват повечето модерни MVC frameworks, но в по-опростен вариант. Истинската полза от изброените стъпки е това, че се разбира защо е необходимо да се предприемат, обяснени са подробно, както и след всяка глава има въпроси и ситуации, които могат да възникнат. Това, което ми липсва, обаче са неща, които са споменати в книгата като възможно развитие, но изрично е посочено, че няма да бъдат описвани и са дадени препратки към други материали по темата. Това са неща като testing frameworks, data mapper / active record database patterns, domain driven design. Липсва ми и отделна глава относно конфигурация на приложението за различни среди (само се споменава), както и error handling. Има и неща, които са излишни и идват в малко повече (споменават се почти във всяка глава): как и какво точно да търсим в кода на целия проект когато се заменят разни структури; кога да направим commit и да известим QA отдела; кога да искаме помощ или какво да кажем на operations отдела за промени по конфигурацията на сървъра и др. Като най-полезни мога да определя четири от стъпките, които виждам доста често, че се пренебрегват при разработката на приложения или просто не са усвоени: 6. dependency injection, 7. tests, 16. dependency injection container.

Continue reading “Modernizing Legacy Applications In PHP”