Devsharp 2018 was held in Gdansk on September 21st, 2018 in the Stary Maneż cultural center. It’s only 15 min away from the Airport so it’s very easy to go there and of course, all the conference were in English.
This free conference was such a victim of its success that they had to increase the number of places. Initially planned for 250 persons, about 400 passionate developers answered the call.
The conference was sponsored by IHS Markit, automotiveMastermind, Carfax and of Course, MongoDB. Seven talks were planned during the day from Microsoft, 8x8, and JetBrains for example.
I also happen to have a slot to speak about MongoDB Atlas & MongoDB Stitch and I explained how you could benefit from our platforms to accelerate and simplify your interactions with your data.
I shared my presentation here so feel free to have a look but I have made a lot of live demos leveraging MongoDB Compass, MongoDB Charts, MongoDB Atlas and MongoDB Stitch so make sure to come and see me on stage next time :-).
I would definitely recommend this conference, especially if you are a C# developer so please feel free to join us next year.
It was also my largest audience I have spoken to so far. I am really proud and I can’t wait to go again next year :-). Special thanks to the team for your warm welcome!
The MongoDB Summer ‘18 Intern Series: From Learning How a Computer Works to Helping Build MongoDB Stitch
Most interns joining us for the MongoDB summer engineering program are in the process of pursuing a degree in computer science and come looking for a hands-on, impactful work experience. As a sophomore in high school, Julia Ruddy was introduced to computer science in a basic CS class that received so much positive feedback, her school introduced an Advanced Topics in CS course to the curriculum for her senior year. When Julia started her freshman year at Princeton University, she decided to pursue a degree in electrical engineering and joined us this summer as one of three interns on our Stitch team. Andrea Dooley : Why did you decide to declare electrical engineering as your major? Julia Ruddy : The Advanced Topics course in high school went very low level. We started the course working with transistors and proceeded to build up to the level of writing a Tetris game. It was interesting to see how it all fit together from transistors and binary to code you can write a program on. It was at that point I considered electrical engineering because as interested as I was in CS, electrical engineering gives you the opportunity to see what’s under the hood. I wanted to understand how a computer worked from 1s and 0s to building something like MongoDB. AD : So you’ll graduate with a degree in Electrical Engineering. What experience have you had with Computer Science? JR : One of my priorities was to keep up with the computer science schedule, so I took a lot of upper-level CS classes. Last summer during an internship at an early stage startup, my work consisted of half hardware and half software. Through that internship, I learned I didn’t want to work in the hardware space. I liked the hardware aspect of my work but found I enjoyed my days doing software more. Although I love learning about it, I find building hardware from scratch to be very tedious, and it’s hard to debug. Also, I find the software industry as a whole more intriguing. AD : How did you first learn about MongoDB? JR : A good friend of mine from Princeton interned here last summer and encourage me to attend the open house. It seemed like a cool place to work and piqued my interest. When I got deeper into the search I found MongoDB especially attractive because it’s an established company, but smaller in size. I know sometimes at larger organizations your work can get lost, but my friend vouched for the work he did here, and that it impacted the business. AD : As someone not fully immersed in CS as other intern candidates might be, did you find the interview to be particularly difficult? JR : From my experience, software interviews, in general, follow a similar pattern regarding data structure and algorithms. I did a ton of prep in those areas, ensuring I was very familiar with them. During my interviews here, everyone was very approachable and easy to talk to and the conversations flowed naturally. If my interviewers had any hesitations regarding my experience, I didn’t notice them. AD : What team are you working on this summer? JR : I was given my first choice, which was to work on the Stitch team. Stitch is a serverless platform designed to help people focus on the interesting and exciting pieces of their applications, rather than get bogged down with boilerplate and tedious back end code. It’s a newer team for a relatively new product, as well as something people are talking a lot about. I wanted to be on a team that was on the forefront of the upcoming MongoDB release. AD : What project are you working on for Stitch? JR : There is no one concrete project within Stitch. I’ve been picking up tickets, some bigger than others, working on both the front end and back end. Going into my internship, I had zero front end experience and I felt that if I wanted to become a respected full stack engineer, I needed to change that. So, my goal for the summer was to pick up as many UI tickets as I could. I actually really enjoyed front end development and learned a lot. Overall, this summer I’ve been able to work on many different things, which I find to be more similar to what a day in the life of a full-time engineer would be like. I now know what a career in software engineering entails, and it’s fun! AD : What’s one of the bigger tickets you were able to work on? JR : One of the bigger tickets was to create a generic AWS service in the UI, which allows for an extra layer of ease for our users. They used to have to edit code themselves to do more specific actions, but now they can choose from a drop down. I’ve also been working through a series of UI tickets for Stitch usage metrics, which is a real time visual representation for users to see how much data they’ve used, and how many transactions they’ve done, which will help with transparency in billing. AD : Aside from project work, what has been one of the most memorable aspects of your internship? JR : I worked with a group of interns on a project for Skunkworks, MongoDB’s internal hackathon. We built a computer game for people with minimal technical skills, to help them get familiar with MongoDB query language. The user plays a detective, and the goal is to solve the mystery of the missing emerald leaf in the MongoDB museum by querying databases. When the detective is completing one of the tasks to help solve the mystery, there is a prompt to drag and drop the proper argument into the query. We made it to the final round to present the game to the entire office and won the award for “Most Fun.” AD : Is there anything you learned during your time at MongoDB that surprised you? JR : I found the Speaker Series with our CPO [Chief People Officer] Dan Heasman to be really interesting mostly because it’s the side of a company I don’t ever think about. The idea that there is someone dedicated to fostering a great culture, managing how people interact, and maintaining the vibe is new to me, but he was so clear and concise in his approach I learned that there actually is a science to making people feel comfortable and welcome at work. AD : What’s one key takeaway from your experience as a MongoDB intern? JR : After this internship, I can confidently say software engineering is what I want to pursue after I graduate. One of my worries beforehand was that it was an isolated career, where you code all day and don’t have much interaction with other people, but my experience at MongoDB has shown me that there are always people willing to help, and asking for help, and there is a lot of collaboration in between. It’s been really rewarding to be able to write code that fits into a massive code base like MongoDB, as opposed to working on an isolated project as I would perhaps at another internship, or at school.
MACH Aligned for Retail (Microservices, API-First, Cloud Native SaaS, Headless)
Across the Retail industry, MACH principles and the Mach Alliance are becoming increasingly common. What is MACH and why is it being embraced for Retail? The MACH Alliance is a non-profit organization fostering the adoption of composable architecture principles. It stands for Microservices, API-First, Cloud-Native SaaS and Headless. The MACH Alliance’s Manifesto is to: “Future proof enterprise technology and propel current and future digital experiences" The MACH Alliance and the creation of this set of principles originated in the Retail Industry. Several of the 5 co-founders of the MACH Alliance are technology companies building for retail use cases: for example commercetools is a composable commerce platform for retail (built completely on MongoDB). MongoDB has been a member of the MACH Alliance since 2020, as an “enabler” member, meaning use of our technology can enable the implementation of the MACH principles in application architectures. This is because a data layer built on MongoDB is ideal as the basis for a MACH architecture. Members of our Industry Solutions team sit on the MACH technology, growth and marketing councils, and actively are involved with furthering the adoption of MACH across the Retail Industry What is MACH, why is it important for retail? The retail industry has long been a fast adopter of technology and a forerunner in technology trends. This is because of the competitive nature of the business leading a drive towards innovation- its vital that retails are able to react quickly to new technologies (e.g. NFTs, VR, AI) to capture market share and stay ahead of the competitors. Retailers have realized that to be able to deliver new and value-add experiences to their customers, they have to cut back on operational overhead that leads to increased cost and build standard functionality that can either be bought or re-used. This is where the benefits of MACH comes in- it's all about increasing the ability to deliver innovation quickly while lowering operational costs & risk. Microservices: An approach to building applications in which business functions are broken down into smaller, self-contained components called services. These services function autonomously and are usually developed and deployed independently. This means the failure or outage of one microservice will not affect another and teams can develop in parallel, increasing efficiency. API-First: A style of development where the sharing and use of the data via API (application programming interface) is considered first and foremost in the development process. This means that services are designed to aid the easy sharing of information across the organization and simple interconnectivity of systems. Cloud-Native SaaS: Cloud-native SaaS solutions are vendor-managed applications developed in and for the cloud, and leveraging all the capabilities the cloud has to offer, such as fully managed hosting, built-in security, auto-scaling, cross-regional deployment and automatic updates. These are a good fit for a MACH architecture as adopting them can reduce operational costs and frees up developers for value-add work like new unique customer experiences. Headless: Decoupling the front end from the back-end so that front ends (or “heads”) can be created or iterated on with no dependencies on the back end. The fact that the layers are loosely coupled decreases time to market for new front ends, and encourages the re-use back-end services for multiple purposes. It also de-risks change in the long term as services can function independently. Where does MongoDB come in? MongoDB is an enabler for MACH, meaning that using MongoDB as your data layer helps retailers and retail software companies. achieve MACH compliance. Our data model, architecture and functionality empower IT organizations to build in line with these architecture principles. During a digital transformation, where a retailer is modernizing a monolith into a microservices based architecture, they're looking for a data layer which will enable speed of development & change. MongoDB is the "most wanted" database 4 years running on Stack Overflow's developer survey- this is because our document model maps to the way developers are thinking & coding, and the flexibility allows for iterative change of the data layer. When looking at API based communication, the standard format for APIs is JSON, which again maps to MongoDB's document model. The idea with API-first development is to develop with the API in mind- why not store the data the way you're going to serve it by API. This reduces complexity and increases performance. Cloud Native and SaaS products have become the norm as retailers wish to reduce maintenance and management work. MongoDB Atlas, provides a database-as-a-service, guaranteeing 99.995% uptime, automatic failover and self-healing and allowing DevOps engineers to spin up databases in minutes or by API/ script. Many retail software companies are also built on MongoDB Atlas- for example commercetools, which provides an ecommerce solution as a SaaS product. Headless architectures require a data layer that is able to adapt and change for new workloads. The ability to change the schema at runtime, with no downtime, makes MongoDB's document model ideal for this. Performance and the ability to scale for new "heads" is also important. MongoDB is known as a high performance database and can scale vertically automatically or scale out horizontally seamlessly. So MongoDB becomes a great choice for retailers choosing to adopt a MACH architecture (see figure 1 below). As a general purpose database with high performance, a rich expressive query language and secondary indexing, MongoDB is a really good fit as a data layer as it is capable of handling operational and analytical needs of the application. FIgure 1: Example of a MACH architecture Want to know more? Are you interested in a transition to MACH? Dive into our four part blog series exploring each topic in detail and how MongoDB supports each of these principles: Microservices API-First Cloud-Native SaaS Headless