Have something to share about engineering practices, architecture or DevOps?
Become a speaker now

Archive for September, 2015

Confession of An Engineer

We all are professionals, e.g. software engineers, quality engineers, technical/team leaders, project/product managers, etc. But we all are humans too. Often due to different reasons, like tight deadlines, push from customers/clients, etc., we all tend to neglect common sense and omit important practices. In this talk based on my both positive and negative experience we will review some patterns how we make common mistakes and what terrible results they may lead us to.


Product Requirements: where they are coming from?

Have you ever had any of these thoughts:

  • Why are we working on this?
  • Others have this feature, shouldn’t we match the competition?
  • I was redoing it for 3 times, could someone think it through first?
  • Killing a working feature – this is insane. I could build this in a day, how come they work on spec for weeks?

After switching from engineering to product team I’d like to share my discoveries about business side of the product development.

Katya Kameneva

As a QA lead drove improvements of the processes from Test Automation to Continuous Delivery and TDD. Moved to the Product team and continue learning about Lean product development, Design Thinking and more.

UX Design & Agile

How do squeeze UX/UI design into agile practises? How do you insure you have right deliverables at right moment?

There is more than one way to do it effectively. There is more than one way to fail. Over a course of years I’ve been working as UX designer with development team practicing agile methodologies and I’d like to share some insights and practises I use.


Tanya Zavialova

Tanya believes that good design must be elegant, clean and functional.

Started her professional career as a web-designer in 2005. Since 2007 I have been working as a user experience designer for various projects including consumer electronics, web, desktop and mobile applications. In 2012 got Professional Doctorate in Engineering degree from Eindhoven Technical University. Tanya likes to be involved in all stages of the design process starting with user needs elicitation, ideation, requirements engineering, rapid and detailed prototyping, iterative evaluation and pixel perfect design. Along with it she is happy to her share knowledge and experience through workshops, conferences and courses she runs.

DCI @ XING – same same but different

We write a lot of object oriented code at XING. Despite the ease of development with modern tools, we weren’t quite happy with the code produced as our codebase grew and matured until we introduced DCI (Data-Context-Interaction paradigm – Trygve Reenskaug’s invention, the author of famous MVC pattern).

DCI has become a hype word in recent years, yet one can hardly find evidence of real-life applications out there in the Internet. In this talk I’ll demonstrate how XING applies DCI to connect the important Agile practices and techniques such as DDD and TDD into a seamless development process, giving a revive of spirit to a long-lived OOP paradigm.


Boris Tveritnev

Boris Tveritnev is a software developer who believes that simple systems are better than complex ones. He likes to speak about various approaches to achieve desired simplicity. He currently works as a senior software developer at XING in Payments and Billing service team. Besides that, he maintains and contributes to several open-source projects and independently develops security solutions for retail markets.

Don’t let your code to be illiterate along with your colleagues

Do you remember you saw in the code method with name “getCatalogVerion()” or variable name “reimbusmentEntrys” or comment “necesarry”? If you’re an Eclipse user I’d say you’re lucky, IntelliJ guys are not. Why? Because they see those silly mistakes after Eclipse guys checked code in. If you’re an IntelliJent person and do not want to make a “holly war” come to my talk – I’m going to share a good practices to keep your code “clean” from grammar perspective as well.


Izzet Mustafaiev

Primary skills are in Java, hands on coding with Ruby/Groovy, exploring FP with Erlang/Elixir, system programming with Rust. Participated in different projects as a developer and architect. Fun of XP practices, crazy about automation, still trying to see continuous delivery in a real life. Advocating Clean Code and DevOps habits and practices, speaking at engineering conferences like JEEConf, XPDays, AgileEE, JavaDay, InfoShare, EPAM SEC. Away from work I’m a family guy, raising a son; time to time doing BBQ parties, gardening and traveling.

Automate everything you should

Nowadays computers are tremendously fast and powerful. All their cores, RAM and gigahertz’ are to our service. And seems like we have come to the point when we cannot make them 100% loaded.

Even we, software engineers, do a lot manual stuff. Manual testing, debugging, packaging, deployment – all that can and should be automated. In this talk Serhiy will sell you automation idea explaining what benefits you (developer, QA, manager) will get from it every single day.


Why to bother with writing test? Nobody cares?!

  • Why to bother with writing test?
  • You don’t see a benefit of writing tests first?
  • They slow down your app development?
  • Hard to create a name for the next describe\it?
  • You are forced to write the tests?
  • Or you doing it for money?

After this talk you will love to write test! Or at least understand why other do (note: no money back guarantee, sorry).


Dmitriy Shekhovtsov

MEAN Lead and mentor. Passionate JavaScript developer, open source and Angular believer. Always using best edge technologies to achieve shiny results.

Escaping from the automation hell

We build software that runs on 21+ platform with millions of users and billions of deployments. Our software engineers have to keep the high pace of quality. More than 500k tests are executed daily. In this talk I would like to share my experience of dealing with unstable and long running tests, collecting, aggregating and analysis test execution data.

Yan Drugalya

Professional C++/C# developer. Over 14 years of successes and failures. Occasionally writes code in JavaScript, Perl and Python. As his day job builds tools to enhance QA/R&D productivity.

What does it mean to be a test engineer?

Test engineering is hard, even harder than software development. Being test engineer puts you in a wider context, with no clear boundaries. You have to find those by yourself. This requires courage. Courage to take action, courage to make mistakes. As a test engineer, you do mistakes every day. You do them so often that sometimes you feel you can predict the future. Scientific explanation to this phenomena is patterns recognition. It is an ability of our brain to match the information from a stimulus with information retrieved from memory. Defect prevention is hard. Together with technical skills one have to develop high social awareness. Working on safety nets never was so important, different types of checks on different levels to make sure software is reliable and serves its purpose to the variety of everyday use-cases. We know that life is so complex and sometimes complicated which makes it impossible to predict all possible outcomes and scenarios. But striving for excellence never was so important as nowadays in such an open, transparent and competitive environment.

Goal of my talk will be to show you my everyday job as a test engineer. Not only how to look for defects, but how to prevent them from happening. Not only how to automate tests(noun), but how to build safety nets to minimize end-user impact. Not only how to inform testing status but how to influence quality on company level.


Pair Programming: how to do it right

Pair programming is the key to XP. It is the bedrock practice which marks XP as being team-focused rather than individual-focused. There is evidence that it is a very effective practice. So why is it not more common? This presentation examines pair programming in detail.


API Driven Development

The general idea of this talk is that you define your application data, structure and everything to do with the data/API side of your application before you write a single line of code. It’s a constructive methodology that lets you think about what you are going to build before actually building it. This talk will cover test driven development of your API and database structure with the examples in JavaScript, Node.js and C#. The methodology is language agnostic though.