Welcome to Part 4 of an ongoing series with ShuttleCloud engineers discussing projects, bottlenecks, and whatever else is on their mind.
Below is an interview with Lukasz Gradzki, Software Engineer for ShuttleCloud who lives in Madrid, Spain.
At a Glance
Name | Lukasz Gradzki
Role | Software Engineer
Background | Web applications, Python, APIs, Integration
I finished my Masters a year ago while working on side projects. Immediately following graduation I freelanced with a Polish company, building systems for both management and electrical plants. I wrote this software in Java and Python/Django for 2 years, remotely from Spain.
In addition to freelancing I also developed Rugatu, a popular Bitcoin forum.
What’s your role at ShuttleCloud?
My job is to integrate our front-end applications with the backend systems. Though my main responsibilities are front-end specific, we have a fun policy at ShuttleCloud that encourages us to rotate work duties and not get too ‘sticky’ with a single project. Because of this I’ve also enjoyed working on other parts of the platform such as provider endpoints.
Most of my work is with enterprise migration portals like Comcast and TWC. When I’m not helping deploy a new application I work with our DevOps Engineer Pancho on infrastructure or with Senior Software Engineer Félix on contacts migration endpoints.
How have you contributed to the platform?
When I started at ShuttleCloud my first project was to redesign the portal application from the backend, changing the way it works by modifying which data structures we used. The biggest change we made was when we started using the Django framework in a new way:
The standard Django approach suggests implementing views as separate functions. Doing this, however, resulted in limitations that were not acceptable to our specific use cases and we applied an alternative design: each front-end application is now represented as a single class whose methods provide the basic business logic and interfaces.
This solution drives our class-based web applications with a data-driven model. Such a design separates views completely, and by storing an entire application within one class we’re able to reuse the design when we develop similar applications for new clients. By making only slight modifications to a design class we can keep the backend identical. This method significantly reduces implementation resources and development time for our clients.
What bottlenecks have you encountered?
When end-users provide credentials for their cloud platform accounts, our application triggers an authentication process with each provider’s API or IMAP/POP protocols. In this way, users of our self-service tool are essentially authorizing themselves. In the case of integration with 3rd party services, however (such as Google integrating with our API for Gmail) we had to automate this process as much as possible. We managed to partially automate this tokens interchange process which requires less interaction from the end-user.
Describe a project you’re proud of.
I’ve been working on a tool for Google Apps Admins that I’m really excited about, however it’s still under construction so I can’t go into much detail. The design and functionality are almost ready, and after some polishing and larger scale testing we should be ready for launch. I’m wrapping up this tool once some of our current projects are closer to the finish line.
Besides that, the migrations API for Gmail is a huge deal for me. This is the first time in my life I’m developing a tool that will be used by millions of people around the world, and I’m very proud to be part of the team working on it.
What technologies do you use?
Most of our applications are written in Python, which is my strongest programming skill. Apart from using it as a pure language with imported libraries, we also use the Django framework to facilitate the development of front-end web applications.
How have you grown since working at ShuttleCoud?
I learn something new every day, especially from the other guys on our team. We do a lot of collaborative pairing sessions where a few of us work on the same thing, on the same computer, at the same time, discussing solutions and risks in an agile way.
Doing this allows us to produce more cogent solutions with 3 brains working on a single problem, and furthermore this lets us to learn from each other. We all come from different environments and backgrounds, so interacting with people in this way makes learning something new an inevitability.
If you want to double up your development skills, you need constant contact with other developers around you. By observing how other people think and derive solutions, you find more objective paths that you’d never figure out yourself.