XP Days Ukraine 2014 - Refactoring legacy codeDmytro Mindra
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.
Стандарт OMG Essence - в чем польза для аналитика?Yury Kupriyanov
"Режиссерская версия" слайдов к докладу "Стандарт OMG Essence - в чем польза для аналитика?" на ЛАФ'2013. Полностью приведены чеклисты для стадий альф: стейкхолдер, возможность и требования.
XP Days Ukraine 2014 - Refactoring legacy codeDmytro Mindra
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.
Стандарт OMG Essence - в чем польза для аналитика?Yury Kupriyanov
"Режиссерская версия" слайдов к докладу "Стандарт OMG Essence - в чем польза для аналитика?" на ЛАФ'2013. Полностью приведены чеклисты для стадий альф: стейкхолдер, возможность и требования.
Все проекты начинаются с определения требований к проекту. Однако то, каким образом записаны эти требования, сильно влияет на успех проекта. Что значит управлять требованиями гибко? Как управлять требованиями с помощью историй пользователей? Какие подводные камни могут нас ожидать?
закон иерархических компенсаций седова и C++ core guidelinesCOMAQA.BY
Стандартизация шагает по планете широким шагом. Почему создание сложных систем невозможно без подведения общего знаменателя и принятия стандартов? Можно ли объяснить этот факт с научной точки зрения? В докладе мы рассмотрим как общие вопросы стандартизации и развития информационных систем (в чём нам поможет великий советский ученый-практик Евгений Александрович Седов), так и погрузимся в стандартизацию практик кодирования нашего любимого языка - C++ Core Guidelines
Описание проекта по разработке обучающего курса для страховой компании по теме противодействия легализации доходов, полученных преступным путем, и финансированию терроризма.
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Methods for building dialog agents and the technologies we used Grid Dynamics
Chatbots have now become an integral part of software development, which are closely related to both NLP and ML. The present report highlights the basic concepts and approaches of working with NLP by implementing dialogue agents (Intent classification, NER, Slot Filing), and you can also find out how to build an entire dialog system. No SaaS, only in-house solutions!
Все проекты начинаются с определения требований к проекту. Однако то, каким образом записаны эти требования, сильно влияет на успех проекта. Что значит управлять требованиями гибко? Как управлять требованиями с помощью историй пользователей? Какие подводные камни могут нас ожидать?
закон иерархических компенсаций седова и C++ core guidelinesCOMAQA.BY
Стандартизация шагает по планете широким шагом. Почему создание сложных систем невозможно без подведения общего знаменателя и принятия стандартов? Можно ли объяснить этот факт с научной точки зрения? В докладе мы рассмотрим как общие вопросы стандартизации и развития информационных систем (в чём нам поможет великий советский ученый-практик Евгений Александрович Седов), так и погрузимся в стандартизацию практик кодирования нашего любимого языка - C++ Core Guidelines
Описание проекта по разработке обучающего курса для страховой компании по теме противодействия легализации доходов, полученных преступным путем, и финансированию терроризма.
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Methods for building dialog agents and the technologies we used Grid Dynamics
Chatbots have now become an integral part of software development, which are closely related to both NLP and ML. The present report highlights the basic concepts and approaches of working with NLP by implementing dialogue agents (Intent classification, NER, Slot Filing), and you can also find out how to build an entire dialog system. No SaaS, only in-house solutions!
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Архитектурные решения при создании облачного сервиса на Asp.NetGoSharp
На конференциях часто рассказывают, как хорошо и удобно разрабатывать облачные приложения на той или иной платформе. Однако при реальной разработке возникают вопросы, которые обычно обходят стороной. В докладе я расскажу с какими неочевидными проблемами столкнулся при разработке сервиса под Microsoft Azure, и каким образом эти проблемы были решены.
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17OdessaFrontend
Если еще несколько лет назад фронтенд это часто был простой и понятный интерфейс между пользователем и бекендом, то на сегодняшний день с учетом обилия фреймворков, либ и все возможных новшеств, фронтенд уже можно считать полноценным отдельным приложение со своей логикой и множеством подводных камней именно по этом сегодня как никогда важно задумываться о том, а как обеспечить простой и понятный процесс тестирования вашего фронта?
Как сделать так чтоб покрытие авто тестами не стало для вас болью или не для вас, но всё еще болью? Дмитрий Хименес обращает ваше внимание на несколько простых моментов, которые стоит учитывать при разработке фронтенда, чтобы сохранить возможность безболезненно сопровождать его автотестами.
Виды QA: Всё что вы не знали и боялись спроститьGoIT
19.02.2015 состоялось очередное событие, посвященное тематике Тестирования ПО.
Встреча помогла участникам
• разобраться в видах QA;
• получить информацию о «подводных» камнях каждого из направлений;
• узнать о специфике работы тестеровщика;
• перенять опыт тестировщиков с многолетним стажем;
• узнать о нововведениях в мире QA;
• выбрать свой путь развития в тестировании.
Спикерами выступили:
Александр Майданюк – QA Lead, Manager, QA Consultant и Trainer. Занимает позицию Head
of Quality Assurance Solution в Ciklum. Эксперт и судья QA секции чемпионатов UA Web
Challenge. Соучредитель Киевского Клуба тестировщика QA Club.
Николай Ковш – QA Engineer в Ciklum. Является ярким примером свитчера - человека,
который сменил область деятельности. Со-организатор ивентов в QA Club - самом большом
киевском сообществе тестировщиков. Николай расскажет, почему тестировщику важно
научиться программировать.
Марина Шевченко – Mobile QA Engineer в Ciklum. QA з досвідом тестування веб, дестопних
та мобільних додатків. Співорганізатор заходів в QA Club – найбільшій київській спільності
тестувальників.
Third bullet: As if that’s not enough pressure.. Hopefully I’ve convinced you that API design is important. But why is it important to you personally?
If you get it right, it looks obvious in retrospect. It’s a good sign if people say: “of course that’s how it should look; so what?” Appropriate to audience: a good API in C++ might be a bad API in Java; a good API for economists might be a bad API for physicists.
So now you know the characteristics of a good API. In the remainder of the talk I’ll outline the general principles that lead to good APIs and specific attributes of Class, Method, and Exception APIs that lead to goodness. Finally I’ll conclude with a couple of quick examples API refactorings. First two sections are a bit fluffy but the last four are chock-full of code examples
Mention “subtle color code”
Худшее, что Вы можете сделать, это провести 6 месяцев над написанием 248-страничной спецификации прежде чем показать ее кому либо. К этому моменту Вы не сможете отказаться от API даже если принципиально ошибочно.
A static utility class containing decorators for applying retry policies, and static factories for the retry policies themselves. This one-page description isn’t yet a true specification, but it’s good enough to evaluate and improve the API. So how do you evaluate it?
You write code to it, early and often! Examples are among the most important code you’ll ever write to an API. They form the basis of thousands of actual programs so any good practices are magnified a thousand-fold, and and bugs pop up in a thousand places.
It’s best if different people write the plug-ins. The you test SPI doc as well.
I don’t mean that you shold take one API component from everyone and throw them together into a rude semblance of an API; that’s a recipe for disaster. Rather, you should come up with a unified, coherent design that represents a compromise among all the stakeholders in the API. You generally can’t fix API mistakes outright, but you improve things by making judicious, compatible additions
That’s all I have to say about the process of API design, now onto the principles of what makes for a good API design.
Often these names are metaphorical in nature, e.g. Publish-Subscribe service. (Some of these ‘bad’ names cross the line into ugly.)
If you remember only one thing in the talk, this is it. Conceptual weight, sometimes called conceptual surface-area
Не всегда легко понять, что входит в детали реализации. Хороший настраиваемый параметр : размер пула очередей ; плохой : Число элементов в хэш-таблице.
This advice is somewhat controversial, and is less applicable in a research setting
Parnas said it better than I ever could, so I’m simply going to read you what he said: I don’t know about you , but I find that inspiring. I’ve got religion. <next slide> and the only thing to do about it is to document religiously.
There is no excuse for an undocumented API element – period
(Next slide contains Dimentsion ex.)
Here’s an example from Java’s awt
That’s the last general principal I’m going to talk about.
Now let’s see how all of this applies to class design
This idea is central to functional programming
In plain English, ask yourself “is every Foo a Bar”? Unless you can say yes *with a straight face*, Foo must not extend Bar.
That’s all I have to say about class design
Now on to method design
Here’s and example from the W3C DOM API
Here’s a particularly egregious example of what not to do
I believe that method overloading is overused
Mention that Builder pattern is a special case of breaking up the method Nasty example from Win32 API
The get method on ByteBuffer in Java’s nio package violates this advice ThreadGroup.enumerate returns void
In a language that has checked and unchecked exceptions, …. A checked exception represents a strong statement by the API designer that a method can fail in some way, and the programmer should consider this and attempt to take corrective action. If you can’t take corrective action, then it shouldn’t be a checked exception.
Two quick API refactorings
This is an example where you win by solving a general problem
Around 1996 many people wrote thread-local variable implementations in Java. Most of them looked like this:
Code to assign a serial number to each thread and print a thread’s serial number Notice that outer class class is noninstantiable, and each of its static methods takes a single instance of the inner class. So why don’t we move the set and get methods onto the inner class? Once we do that there are no methods left on the outer class except the getKey static factory. So why don’t we do away with the outer class entirely? This is what we’re left with:
This is essentially the ThreadLocal API that Java adopted in release 1.2 Notice that it’s trivial to generify this API. It was impossible to generify the first API, and difficult to generify the second.
Not a glory profession - API designers like plumbers. Your APIs won’t be perfect, but with a bit of luck they’ll be good
An homage to Jon Bentley’s “Bumper-sticker Computer Science” in “More Programming Pearls” iJava Best-Practices book with a hidden agenda of encouraging programmers to think about API design **** Timothy Boudreau Jaroslav Tulach: Designing APIs that Stand the Test of Time Thursday 10/26, 3:30 P.M.