We’re kicking off our developer interview series with Sebastian Novak, a web developer at RT-RK, a company that’s a pioneer in home automation, embedded software and testing tools. These interviews are meant to give insight into everyday developer life and their view on software development
For a start, can you tell us a little bit about yourself and your role at RT-RK?
I’ve been doing professional development since the first year of University and I’ve been tutoring students enrolled in pretty much every Computer Science course at the University.
My first job was at RT-RK in Research & Development. The team I was working with was pioneering the TV-Centric Game Development (using Android phones as controllers and Samsung Smart TVs as displays). This technology was fully adopted by Samsung later on.
Since then, I’ve been working at RT-RK’s BBT (Black Box Testing) department due to my Bachelor Thesis, that involved code-generation, metaprogramming and mixing different languages together via various Foreign Function Interfaces. Together with Dejan Stefanovic and professor Dr Milan Vidakovic I’ve been designing and developing various parts of our complex software ecosystem at BBT R&D department. Also, I had an opportunity to lead a small team of graduate students on a BBT R&D project.
I’m part-time involved with the Faculty of Technical sciences and have a class coming up in January, named Java Web programming, as a teaching assistant, that’s gonna be fun.
Hope to get further involved with the Faculty department, to continue working with students and to obtain a PhD via doctoral studies.
What is the thing you most enjoy about being a web developer at RT-RK?
The fact that the things we do at RT-RK are really experimental, cutting edge and sometimes even revolutionary.
Opportunities to work with top talent from Samsung, Google, Sony, Panasonic and to visit their companies on-site and to learn so much from them.
Also, I love using 10+ programming languages in a single day’s work.
Check this out, I work on: - Drivers and device handling - C and optimized assembly, this sometimes includes the usage of Hardware Description Languages, such as VHDL and Verilog - Wrappers for those drivers - C++ - Network TCP/IP magic with packet handling due to some serious requirements for network traffic logging - Some graphical interfaces for native clients C# WPF / Python PyQT - Android clients that often utilize C++ code, which means YAY for a yet another Foreign Function Interface - JNI - Java EE servers and utility applications combined into a functional ecosystem - This backend ecosystem also involves Node.js and PHP - Database magic and reports with SQL and SQL aggregating frameworks in order to produce fancy reports - Frontend applications are written in Java (GWT), Angular, Polymer - And last but not least, SIFU, using a DSL to write a specification in order to generate both frontend and backend code.
You mentioned that you love using a wide span of technologies. Can you point out which one’s are your favourite and tell us more about downsides and upsides of them?
My favourite one would have to be Java, not because of frameworks or IDE’s or anything like that. It’s because of its Virtual Machine. Java Virtual Machine (JVM) was originally designed to solely run Java, but over time, actual languages were developed from scratch or adapted to run on the JVM. The list of languages is quite extensive.
Among them, Jython would be my favourite. A Python language specification that runs on the JVM, enables you to extend Java classes in Python and to do crazy mixing between the two. How awesome is that?
While all of this sounds great, there are indeed downsides. Since JVM was imagined to abstract platform-specific details, when it comes to performance and low-level platform-specific libraries/code, you have to use a Foreign Function Interface or some other technique in order to execute native code. This is sometimes an overhead that turns people away from using JVM.
Any technologies you would like to try in the future?
I’ve heard a lot of talk regarding RUST and I would like to see for myself if what its authors claim is true; by that I mean:
- “Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.”
- “zero-cost abstraction”
- “guaranteed memory safety”
- “efficient C bindings”
Sounds amazing, doesn’t it?
What methodologies do you and your team use?
Since the products we develop are of our own design, most of our development is SCRUM based, determining goals/sprints that will be delivered on a 3-week basis.
We, of course, use CI coupled with TDD during the development of various LINT tools that are employed to verify run-time code written in JS/PY or any other dynamic language.
Some e2e are also included from time to time, as a preparation for a stable release. For a while we even performed automated code review/analysis..which didn’t go so well. I highly support disciplined development, where a pre-defined set of conventions is established. In these scenarios code review can be indeed automated to a high degree.
This, on the other hand, fails miserably with any legacy project handed from one team to another, to another, to another and finally, in the end, it’s going to be handed down to you, the developer who heard scary legends and tales of the project and its code.
Gather your courage and read the first line of the project documentation that states: “ABANDON ALL HOPE ALL YE WHO CODE IN HERE”.
What does your product design and development workflow for BTT look like? Any important lessons you can share with our readers?
When a product requirement is received, a lot of R&D effort is invested to see how it would be designed and developed later on.
The first item on the list is the initial research and design by the system architect(s) in order to establish a foundation that will be required for the next stage. After drafting up an initial design, the system architect(s) have to discuss each segment of the design with the developers that will be implementing it. This stage is equally important as the first one.
When you discuss how a given design should be implemented holes in the initial requirement, and the design itself, begin to manifest. Having everyone’s say in it can sometimes backfire, as not all users are created equal. When a developer imagines himself as a user, using the product he developed, a certain degree of objectivity will be lost. If a developer sees the user’s requirement as invalid, further evidence and arguments have to be brought to the discussion in order to determine if it’s true. If it really is redundant or invalid, then everyone saved a lot of time that would have gone to waste by developing a faulty feature that would have to be removed later on. In the case the requirement was indeed valid and that the developer that complained about it was wrong, at least the task of implementing it will be thoroughly documented.
To anyone reading this, LET YOUR VOICE BE HEARD, sure you might and surely will be sometimes wrong, but it’s very important for everyone to realize how much they contribute by providing constructive criticism!
Could you tell us how you use Sifu and what’s your typical workflow when it comes to Sifu?
Having a large and diverse application ecosystem often means that we have to build a more specialized system on top of an existing one. Sifu helps us do that. I’ll try to explain with an example. Let’s say that we have an Internet of Things system that deals with collecting and presenting data from a large network of sensors, managing those sensors and the networks they belong to.
By all means, this sounds like a large-scale project with a very specific architecture and design. Let us also assume that the project is deployed for several different customers at one point. Each customer loves every part of the system but each of them has their own set of requirements that are just so specific, that it affects the whole system. One approach would be to actually apply those changes and incorporate their requirements into the system. This requires a lot of effort and coordination between developers that implement system-wide changes, making the whole system a lot more complex.
A different approach could make life a lot easier for everyone, but it has its cons as well. This approach would isolate the individual customers needs into a system for itself that relies on the existing large-scale system. This means that the existing system would not suffer system-wide changes but would be integrated with each of the customer specific systems. The con is obvious: instead of modifying an existing one, you have to design & implement additional loosely coupled systems from scratch. From an upper management’s point of view this sounds crazy, but if you use Sifu, in order to generate a significant percent of each system, it doesn’t sound crazy at all. It sounds like an ideal approach, especially in the long run, where main large-system and the customer specific systems can be updated and modified, to a great deal, independently of each other.
What’s the last big realization about programming you had?
It would have been the Don’t Repeat Yourself principle. I’ve always heard people talking about how important it is and I have utilized it in forms that might seem primitive when compared to what Sifu does. For example, generalization of classes, writing APIs, project-specific tools that pre-generate code skeleton based on a template (but without the actual code)… The thought of actually going a step further and using meta-programming in order create a simple Domain Specific Language has always seemed like an overhead to me and not worth the effort. Many developers also share this opinion, with prejudices like: “it won’t work, you’ll never be able to use it on anything else, it’s going to be a waste of time, etc…”. dryTools (the company behind Sifu) has indeed shown me the light and given me hope that times are indeed changing and DRY is going to mean a lot more than just writing APIs. I’ve also used meta-programming for fun, but here’s a change in the way I look at things now: “I see this pattern that’s repeating all over my code, I can’t find a way to refactor the code into something smaller and more reusable. Do I have to write it each time or maybe I can observe the patterns and with the help of meta-programming, create a simple Domain Specific Language and generate the code instead?”
With that being said, I’ve observed some boiler-plate code in the stuff we do, so I’m thinking about writing a generator for it, a DSL would enable me to specialize/adapt the output and to re-use the tool later on.
Maybe I could ask dryTools R&D team for tips on writing my own DSL?
Our answer: Sure, come on over to the office! :)