Last Monday was the last Codebar Monthly and I was happy and frankly quite surprised how I never actually went before. For some reason I always concluded that those who have some years of coding experience will understand everything, it turns out, 1. this is not the case, 2. even with little knowledge most of the talks absolutely made sense to me. So, let’s see them.

First we had a super interesting talk form Rabea about Progressive Web Apps.

Based on definition:

“A Progressive Web App uses modern web capabilities to deliver an app-like user experience. They evolve from pages in browser tabs to immersive, top-level apps, maintaining the web’s low friction at every moment.” (Addy Osmani)

They have some cool characteristics, such as:

  • Home screen access
  • Full screen mode
  • Splash screen
  • Push notifications
  • Exists in android app switcher
  • Works offline

However they have some other pros and also cons:

  • responsiveness
  • linkable
  • no app stores
  • browser support — only chrome opera
  • complexity

The process of these apps are a bit complex but not that complex to be honest. This includes a web app manifest, service workers, background script, front end technology and a proxy between your client app and the network. One coolness is that it can manage a cache of responses. SO after hearing about them the first time, I kinda want to make one now. 🙂

Second we had a talk about Defensive Programming in @quii ‘s presentation. The talk was quite funny but also managed to point out that sometimes it seems that programming is only fun and challenging and rewarding but most of the time it is actually tedious and frustrating, especially when we are not sure whether our code helping or hindering? Accidental complexity is a productivity killer. We must learn from the mistakes, test for many possibilities, be more defensive, be better in general (more thorough) and we have to make our code work in unforeseen circumstances — therefore the defensive programming title. It is kind of like anything that is relying on manual checks is doomed to failure. So for the long-term health of our code it needs to clearly tell a narrative — what it supposed to do.


Third we had an intro to RAM from Mollie Stephenson. I will be honest, I understand as much from RAMs and Hardware as a day old chicken about farming, so I felt I had no idea what was going on, but the presenter is my role model, as she seemed very much on top of her RAM game. I hope one day will slay in the territory of hardware too, hot that I am slaying a lot right now in software (my tests are pretty sensitive this weekend, yay TDD). Anyway, we heard about combinational chips, computing boolean functions, sequential chips, memory, the concept of time and about registers.

Fourth we had @elibelly to talk about Naming Things and how hard it actually is. To sum up our naming classes, methods, everything in code has to be descriptive, meaningful, contextual. So not just others, us, our future self understands this, but it also makes sense. Highly recommended book: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. Alternatively, you can browse through these slides too.

Fifth, and this was our closing talk, we get to know more about Open Source and how to get into Open Source. If you missed the 24 pull request event, keep an eye out, there will be more of these. To cite Charlotte Spencer, Open Source is pretty much FREE CODE! 

It is highly recommended to 

  • explore Github Projects
  • to contribute to something you use every day
  • to start your own project
  • collaborate with friends
  • follow developers, open source contributors 
  • just make you your first PULL REQUEST

Because every contribution matters, even the smallest one, so start small and take it from there. 

See you all next year, I had a lot of fun! ❤

(The post can be also found on Medium under codelog)