PHP in 2020 it’s not your mama’s PHP

I decided to write this post, because before joining Facebook I thought that PHP is just old, limited language from 2 decades ago when server was responsible for simple form parsing, and generating HTML.

I actually learned web development using PHP in mid-2000s, when I was in middle school. I created my personal blog, and website about very popular back then game Deluxe Ski Jump. I actually still have the source code and recently put it on Azure at – it is in polish, and there is no database:P Didn’t bother to update character encoding from ISO-8859-2 to UTF. Why I used ISO-8859-2? Because my cousin told me to do so! It was real copy/paste programmer back then! Good times 😀

Mark Zuckerberg wrote first version of Facebook around that time using PHP too. LAMP stack was the way to go for web development in 2000s.

A few days after joining facebook I realized that PHP now is full blown OO language. It has classes, interfaces, abstract classes, dependency injection, etc. It is much closer to C# or Java than to PHP that I used to write 15 years ago. At facebook we use Hack (typed PHP). It’s awesome. You have the best of two Worlds: type safety and no compilation! Just save, and refresh to see your changes. Yay! As pure PHP performance is not the best, HHVM performance is an improvement.

In PHP, you can access pretty much every module in the codebase without explicitly referencing it. That’s an extra productivity boost. Or hack:) Intellisense in editors like Nuclide (Atom) or VSCode is pretty good as well. When you add Facebook engineering systems, where everything is so neatly setup to prioritize productivity, you are in heaven 🙂 I know most of PHP devs do not have that luxury, but just sayin’ 😉

If you want to learn more about modern PHP, check out these resources:

As of February 2020, PHP is 5th most popular language on StackOverflow (source)! Just recently taken over by python.

In any means I am not recommending you to learn PHP if you don’t have to. Choose Rust or Go instead! Just wanted to let you know, that PHP changed A LOT! PHP in 2020 is not PHP from Web 1.0 times.

Leaving Microsoft…

reseting Microsoft PC

Last Friday, September 13th was my last day at Microsoft. Coincidence was that it was Programmers’ Day = 256th day of the year 🙂

It’s been awesome 5 years! I helped to ship the new Azure Portal, turned hackathon project into Microsoft product announced at //build keynote, helped SeeingAI with a few features, and for last two years helped to grow Azure Search. When I joined the team it was a startup. Now, it’s a mature Azure Service. Along with my everyday job I had awesome opportunities to speak at conferences and meetups around the World about my work. During my time at Microsoft I delivered almost 30 technical talks!

Along that journey I met a lot of awesome and inspirational people. Thanks to them my job was my passion. I was very lucky to have awesome bosses. I want to thank Andrew Birck, Ian Carbaugh, Madhur Joshi, Janusz Lembicz and Pablo Castro for everything they did for me. If you end up working for them, consider yourself very lucky!

Special thanks to Steve Sanderson, Scott Hanselman and Scott Guthrie! Their technical talks made me want to join Microsoft, when I was still in college!

Stay tuned for what’s next!

Azure Search on Azure Friday

Once again I had a pleasure to join Scott Hanselman on Azure Friday. In the past we did a video about Azure Mobile App. This time we talked about Azure Search.

Azure Friday is very casual. You just walk in, and chat with Scott. It just happen to be recorded 😀

In this week’s episode we did a quick overview of Azure Search capabilities. Service, on which, I was working on for last two years.

01:00 – Creating a search index
02:37 – AzSearch.js – Automagical UI and sample React controls
03:27 – Searching the JFK Files
08:00 – Adding search to Scott’s blog

You can deploy JFK Files by yourself. More info in our JFK Files github repo.

Check out AzSearch.js to generate website to search your index!

This is just tip of the iceberg! Check our docs for more! You can start today by creating your first search service. We allow one free service per subscription!

Domain-Driven Design – tl;dr

Domain Driven Design

After hearing about Aggregates and Bounded Contexts over, and over again, I decided to check out what Domain-Driven Design is all about. There is a ton of DDD resources on the Internet, but this blog post is for my personal reference. I am publishing it so I can google it, and maybe you find it useful as well. This post is about what DDD is, and how it can help you to write better code.

What is DDD?

According to Wikipedia:

Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:

  1. placing the project’s primary focus on the core domain and domain logic;
  2. basing complex designs on a model of the domain;
  3. initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

More pragmatic (and ignorant) definition: DDD is software development approach that focus on business processes over implementation details. This allows developers to work with business people more effectively. It also makes code more maintainable and extendable.

Most important DDD terms (buzzwords):

  • Ubiquitous Language – using business terms for naming classes, methods and variables
  • Domain – functionality of the system
  • Bounded Context – components used to deliver a functionality (AKA domains)
  • Value Object – simple, immutable class representing some business term
  • Entity – class with unique identifier, usually used to represent persistent data
  • Aggregate – group of entities
  • Repository – class used to save and retrieve aggregate (AKA save/retrieve data to/from database)
  • Application Service – your Domain(s) communication layer
  • Anti-corruption layer – layer for interaction with external (or legacy) system
  • CQRS (Command Query Responsibility Segregation) – separates querying for data from modifying data
  • Event Sourcing – storing changes to application state as a list of events, which allows to invoke and process events in producer/consumer fashion

Resources to learn about Domain-Driven Design

There are two DDD bibles: Blue Book and Red Book. I’ve been told to do not read Blue Book as first introduction to DDD, because it’s very “heavy” and hard to understand. People were right. I would also add: it’s not very well written (shoot me for criticizing DDD God AKA Eric Evans).

List of recommended resources, sorted in order that I would recommend to follow if you are new to DDD. I strongly recommend positions in bold!

Notice that I placed Blue Book at the end. It’s hard to absorb. It also suffers from low knowledge/pages ratio.

There is also Domain-Driven Design path on Pluralsight that has nice set of courses around DDD and software design.

My thoughts on DDD

Before diving into DDD I was expecting to learn about something new and revolutionary. After reading about Ubiquitous Language, Aggregates and Bounded Context I still didn’t see much difference between DDD and good, SOLID software design. It feels like DDD is mostly about good object-oriented design presented in particular, formalized way with specific buzzwords (aggregate, bounded context, etc.). In Uncle Bob’s Agile Principles, Patterns, and Practices in C#, there is the Payroll Case Study example that is following clean code, good design and implementation practices. If you were put that example into DDD book…it would fit. If you take examples from DDD books and put it into Uncle Bob’s book…it would fit fine as well.

There are however, some new concepts introduced by DDD. Such as Repository pattern, CQRS or Event Sourcing. Are last two actually DDD? Or they are just related to DDD?

DDD is also enforcing designing system around business domain, not around, e.g. database. That is usually a case when designing architecture from scratch quickly. As 99% of apps are CRUDs, ending up with database driven architectures would be natural. You usually start with file->new project, and go from there. This is not a problem for small apps, but might strike later when evolving the app. DDD solves that problem.

If you are familiar with Clean Code and SOLID design as presented in Agile Principles, Patterns, and Practices in C# then DDD does not bring much new concepts to the table. It may make you think more from a business perspective, and consider using new patterns (Repository pattern, CQRS or Event Sourcing) though.

It’s worth to notice that even if you look at Domain-Driven Design path on Pluralsight, there are non-DDD courses about good/clean design as part of the path. Thus, good design is prerequisite of DDD. On top of that we have mentioned earlier buzzwords, CQRS and Event Sourcing.

Going back to DDD terms (AKA buzzwords), they could be also summarized as follows:

  • Ubiquitous Language – use meaningful names for classes, methods and variables
  • Domain – be aware what problem you are solving
  • Bounded Context – group objects that depends on each other
  • Value Object – simple, immutable class
  • Entity – class with unique identifier, usually used to represent persistent data
  • Aggregate – group of related entities
  • Repository – facade over your persistence layer to make it implementation agnostic
  • Application Service – your system’s API
  • Anti-corruption layer – layer for interaction with external system
  • CQRS (Command Query Responsibility Segregation) – separates querying for data and modifying data
  • Event Sourcing – storing changes to application state as a list of events, which allows to invoke and process events in producer/consumer fashion

What DDD enforces from the beginning is layered architecture that may not always be needed. Should you follow DDD in your projects? The answer is, as always, “it depends”. There are some good ideas there, but being over obsessed with favoring DDD in your design decisions over pragmatism will lead to over-engineering.

After TDD and BDD there is DDD. Should you use DDD in all your projects? No. It’s just a way to design software. Also: using DDD does not mean that you need to use all patterns from Blue Book and Red Book.

It seems like DDD should definitely help in long term, but over-engineering (with CQRS and Event Sourcing) may unnecessary complicate things. Actually, I should say: writing SOLID code would help you…and here we are again: is DDD really something different than just good software design?

Seeing AI Photo Gallery

Microsoft Seeing AI

Seeing AI is a mobile app that narrates the world around you. It enables people with low vision to recognize faces, objects, text, bills, colors, and much more! Seeing AI was first announced at //build conference in 2016.

Over last few months I was working with Seeing AI team overnight on in-app Photo Gallery that allows you to browse through photos that you have taken earlier. Before you could only take photo, analyze it, and save (without description). Now, you can save it with description that you can later retrieve. You can also analyze photos taken with your phone camera.

One of the challenges was to decide what details about the photo should we present. We have a lot of different channels (short text, document, person, scene, etc.). For now we decided to show scene description, place and date when photo was taken. Let us know if you have suggestions to improve this!

SeeingAI - photo gallery

Another problematic part was deciding how to distinguish between analyzed, and not analyzed photos. Initially we had a toggle to switch between recognized photos and all photos. Ultimately we decided to have only 1 view with all photos. Thoughts?

For non recognized photos we needed to provide mechanism to analyze them. Initially user had to open photo, and explicitly tap ‘analyze’. We changed this approach to automatically analyze not recognized photos when going to full screen view, and enable users to reanalyze them. The ‘reanalyze’ button might be useful in situations where we update app with new AI models. These models may do better job in recognizing photos.

Seeing AI is built with Xamarin iOS native. I was surprised that we had to build entire gallery from scratch. There was no plugin or open source sample we could use. Hint: opportunity for you!

You can download Seeing AI from App Store.