As you would probably guess from the name of the event, it did not have much in common with regular conferences (as Callum jokes, the event is more based on anarchy). The idea behind unconferences is that there is no schedule, and the ones who define the schedule on the go are actually the participants. Everybody writes their topic of interest on a piece of paper, all the pieces are then collected together and positioned on a board. Participants then vote for their topic of interest and attend those sessions. After a couple of hours of proposing discussions and voting, we came up with a schedule.
The unconf schedule
Since it was impossible to attend all discussions, only some of them will be highlighted in the post.
Large Scale Meteor Deployment
Obviously the question that bothers everyone, including Jordan and Dimitar, who initiated the talk. Does Meteor scale? And how to write Meteor code that scales? The topic is very broad, and the general rules for writing scalable code still apply, that’s why I will share only a few of the points.
“Be careful what you publish”
Yes, reactivity is the coolest feature of Meteor, but it doesn’t come without trade-offs, when it comes to scaling. Every subscription results in exponential scaling problem, occurring at MergeBox. Think twice before subscribing. Are you really seeking for reactivity at this component? Or how likely is it the user’s first name to change?
“Apollo might be the solution”
Based on the previous point, it turns out that in many cases DDP might become a blocker. The synchronization with the client is a heavy process, and it might become even heavier if developers write code without query scope in mind. The Apollo project might be the possible solution to the problem.
“Do not solve problems that you don’t have.”
It is true that software needs to be designed for scalability. But for God’s sake, do not solve problems that you don’t have. In many cases scaling doesn’t matter, and when it does – it means that you (your company) are doing a good job. And trying to write scalable software for an internal system used by 100 employees is plainly loss of time. Yes, I know it will sound contradictory, but before rushing to solve scalability issues, estimate if the add-more-hardware solution might be cheaper in the long run. Try not to be obsessed with scalability, until it does start to matter. And when it does, there might be a bunch of solutions out there.
Designing The Lean Startup
Everybody was curious to learn from the startup experience of Garwin, who initiated a bunch of sessions during the day. Several very strong points were taken out of his first session. Usually developers are very tempted to immediately start coding when an idea pops up in their mind. That is great, but validation of the idea in real world might save months of effort. Or, in parallel to the point about solving problems, it may turn out that your software is great, but solves problems that nobody cares about.
Before proceeding with any implementation, step out of your comfort zone and validate the idea in the real world. One of the validation approaches that was demonstrated is using the Lean Startup Machine Validation Board. You start adding various assumptions and hypothesis on the board, and then get in touch with people who potentially might have those problems. This way you either validate/invalidate your assumptions, and get closer to defining the MVP (Minimum viable product).
Demonstration of Telescope
Xavier, a core member of the Telescope project, briefly explained about the platform and demonstrated its power and flexibility. Telescope can be considered as a developer-friendly Wordpress, written in Meteor and React. It provides components for bootstrapping any kind of content-driven applications: blog posts, comments, categories, user authentication, comments, etc. For the time being the project has more than 4800 stars on GitHub, and it was exciting to follow the demo of Xavier, who is definitely proud to be a contributor to the project.
Architectural pattern in Meteor
During his talk Oleksiy explained about the common pitfalls Meteor developers should avoid. Those can be summarized as: use collection helpers, write granular code.
Make sure to check the presentation slides about collection helpers.
The wrap-up discussion
The last hour of the event was in the format of an open discussion with 4 rock stars of the Meteor community: Callum, Garwin, Simon and Uri. Various topics were discussed, each of them deserving a separate blog post: Apollo, Redux + React, Redux + Angular, Firebase, future of Blaze, etc.
And in order to digest better the information from the whole day, we all decided to head up to the local bar on top of the mall. After a couple of beers everybody started to better understand the underlying concepts of Meteor, and everybody was a bit better of an entrepreneur.
Meteorites Preparing for Beer