Friday Night Dinner: East Street by Tampopo – Derick Rethans

Friday Night Dinner: East Street by Tampopo

The idea behind going for a different restaurant every Friday is to try out a wide variety of places, but also of cuisines. We are lucky that in London, we have access to pretty much any sort of dishes we fancy.

Sometimes, you can even find a wide variety of different culture’s food in one place, and East Street is such an establishment. It is situated just North of Oxford Street, close to Tottenham Court Road station. It specialised in what can only be described as pan-Asian.

Their menu is extensive, from Szechuan dishes via Japan and Korea to Indonesian and Malay. We started with two of their small plates, the Malaysian Satay Chicken and Korean Popcorn Chicken. They were both delicious, very flavourful and moorish. Good Satay Chicken I remember from my parent’s Indonesian friends, and this was just like it. With our starters, we enjoyed a lovely Hokkaido Negroni as we didn’t think a bottle of wine would fit with this menu.

Choosing the small plates was hard, as there are so many nice sounding ones. Instead of ordering them all, we also picked a large plate each. I ordered a Rendang Beef Curry, again, with memories of the Indonesian Restaurants you find in the Netherlands. It was accompanied by rice, peanuts, boiled eggs, and some pickled cucumber. My companion ordered a Tamarind Chicken, slices of well cooked moist chicken in a delicious sticky tamarind sauce. It came served with rice, broccoli and crispy onions, this was one of the non-spicy options on the menu, but despite the lack of chillies still had a bit of a kick. Again, not wanting wine, we picked a bog-standard Tiger beer to wash all the delicious flavours down, which paired pretty well.

Although we were pretty full, we could not quite resist the churros, and shared three with a tasty caramel sauce. I don’t quite understand how they fit in an Asian kitchen, but they were delightful regardless.

If we were to return, which seems likely, we would probably have a meal made up of more of the smaller dishes (all of which sounded delicious) instead of going for the traditional starter plus main course approach.

The place was pretty full, and when we left I remarked that we were probably amongst the oldest of the clientele, but we didn’t feel out of place. Which I think is a good sign.

Interior
1 / 5

Chicken Satay
2 / 5

Popcorn Chicken
3 / 5

Tamarind Chicken
4 / 5

Rendang
5 / 5

Friday Night Dinner: Empire Empire – Derick Rethans

Friday Night Dinner: Empire Empire

We visited Empire Empire on a chilly January evening. The restaurant was fairly quiet but even at 18.30 there were some tables seated and enjoying their food.

The restaurant features an old fashioned jukebox type vinyl record player close to the entrance and has a photobooth for some fun snaps should you be so inclined.

We had a beer each from 40ft Brewery in Hackney, which was lovely. It’s great to see an Indian restaurant branching out from the usual cobra and kingfisher options. We started with poppadoms and dips, and then I had a well spiced biryani with incredibly tender lamb falling off the shank and a pastry lid. My companion really enjoyed her Empire Butter Chicken and a naan bread. This was not as rich as some butter chicken curries, but was incredibly flavourful with a nice level of spicing and kick. Unfortunately we were both too full to move onto try what sounded like tasty desserts from the menu.

Service at Empire Empire was very welcoming and attentive (and quick, but not rushed) we were out and heading home on the bus about an hour after sitting down.

Friday Night Dinner: Lokkanta – Derick Rethans

Friday Night Dinner: Lokkanta

As first restaurant of the year, we wanted something low-key. Not far from Paddington station, on Westbourne Grove, there is a whole row of such places. We settled on Lokkanta, a place that specialises in Turkish food.

We started off with Turkish sausage slices with halloumi, while we were waiting for our main course. At the same time, we started enjoying our delicious red wine from Turkey.

The front section of the restaurant features a well ventilated charcoal grill upon which most of the meats were roasted. In my case, a well cooked and flavoured lamb shish. My partner picked a Yogurtly Adana, minced grilled lamb with bread and basted in a tomato sauce and yoghurt.

The service was speedy, and we did not have to wait long. Perhaps that was mostly because when we arrived at 18:30, there was only other table enjoying dinner, so we were almost the only customers. When we left, there were a few more people enjoying their dinner. However, with the restaurant being quite empty, it perhaps lacked a bit of ambience and the tiled interior made it feel a little clinical, I think it would be quite different if it was busy with plenty of hustle and bustle.

In short, the food and wine was good, but the atmosphere was unfortunately missing.

Friday Night Dinner: Ma Petite Jamaica – Derick Rethans

Friday Night Dinner: Ma Petite Jamaica

What do you need on a cold and dark winter evening? Exactly, a bit of tropical warmth. Our booking was a little last minute, as we hadn’t really thought about arranging something for the last Friday of the year. My wife, who often takes the lead in picking our Friday evening restaurant, suggested this Jamaican place in Camden, not too far from where we live.

We arrived to find the dining room partially full, with Jamaican musing playing and (fake) palm trees. It gave a happy and homely feel to the dining room.

I had never had Jamaican food, so decided that I wanted to try the staples. As my starter I picked the ackee and salt fish, which was served with fried dumplings. My wife chose the chickpea and pumpkin curry. We also decided to share a portion of the jerk chicken spring rolls. All three small plates were very flavourful. With enough hints of scotch bonnets to add a kick, but nothing too overpowering. The dumplings were great for dipping up the sauces.

Because we felt we needed to escape from the cold, we enjoyed a pair of Jamaican Mule cocktails, with our starters, and later mains. The first set was half price as it was still happy hour! There were also a number of Jamaican beers on offer, with a Red Stripe on tap.

I selected the curried goat with rise and peas as my main course. My wife wanted to order a wrap, which they were no longer serving, although they were on the menu. She ended up with their vegetable curry with a roti. Both were excellent.

Our only regret was probably ordering too much food. One and a half starter, and a full main per person was certainly too much. But that’s not the worst problem to have if your dinner was so tasty.

Friday Night Dinner: Noon – Derick Rethans

Friday Night Dinner: Noon

Even when we’re out of the country, we try to keep our tradition in place, and so we found ourselves on a cold and rainy evening at Noon, in Maastricht, in the Netherlands.

When we arrived just after 18:00, the restaurant was already quite full. With a few dozen tables, some high tables, and a bar where a bar keep was making plenty of colourful cocktails. We were seated at a high table right in the middle of the stylishly appointed establishment.

While enjoying a glass of cava, we shared a couple of starters. The Drunken Salmon (salmon cured in gin and yoghurt), and the Asian slow-roasted Pork Belly. Both were excellent. Flavourful and succulent.

For my main, I chose the Asian Ribs. I realised it was another Asian-flavoured dish — I know, “Asia” isn’t a country. I am usually not keen on ribs, but these were boneless, and that made all the difference. That, and the lovely, and slightly spicy sauce that was slathered over the ribs with a few tiny bits of red chilli.

My partner’s choice was the butter steak, medium rare. That came with carrots and a delicious mushroom foam. The sauce was made with Pedro Ximénez sherry, and had a nice shine to it. With our mains, we each enjoyed a glass of Merlot. The only (minor) let down were their chips that were served with our mains. They were slightly chewy.

It was a very enjoyable meal in a charming environment, and with very reasonable prices. A great birthday meal!

Advent 2023: PSR-15 – Matthew Weier O’Phinney

I’ve mentioned a few times over the course of this 2023 Advent series that the longer I’m in the tech field, the more I appreciate and favor simple solutions.
I was reminded of this yesterday when I read this article on return types in Laravel controllers by Joel Clermont.

Request

Please, please, please do not take this as an attack on Laravel or on Joel.
I have nothing but respect for Joel, and while I’m not a fan of Laravel, I’m also not a hater.
It’s never a bad thing to have a popular framework that brings folks to a language; Laravel has done that in spades for PHP.

Summarize the article, already…

In the article, Joel notes the problem with providing return types in a Laravel controller is due to the fact that it could return a view, a JSON response, an array, a redirect, or more.
If there are multiple types that could be returned, based on the request context, you would need to provide a union type.
And if you refactor or make changes to the controller later that result in new types being returned, you now need to remember to change the return type declaration.

In other words, it introduces brittleness.

So what?

I’ve worked on multiple iterations of a major MVC framework, and I ran into these same issues.
As PHP’s type system got incrementally better, the cracks in how frameworks interact with controllers became more evident.
Personally, I find the increasing number of type capabilities in PHP to be a huge boon in helping the correctness of applications, and preventing whole classes of errors.
But if the framework prevents you from using the type system, or makes adding type declarations into a situation that can now introduce errors, it puts the developer and maintainer of an application into a problematic situation.

What are the alternatives?

I worked for quite some time on PSR-7 HTTP Message Interfaces, largely so that we could have a proper HTTP message abstraction in PHP on which to build a better foundation for applications and frameworks.
From this emerged PSR-15 HTTP Server Request Handlers (which I sponsored and collaborated on, but was not primary author of).

What I love about PSR-15 is that there is no ambiguity about what you return from middleware or a handler.
You return a response.
That’s all you can return.

This means there’s no magic about different return values resulting in different behavior from the framework.
You don’t need to keep a mental map about what will happen, or do a deep dive into the framework internals to understand the ramifications of returning a view versus an array.

Instead, your handler will create a response, and provide the logic for how that is done.
If you need html, you render a template, and feed it to the response.
If you need JSON, you serialize data to JSON, and feed it to the response.
If you need a redirect, you create a response with the appropriate status code and Location header.
And so on and on.

Yes, this can lead to a little extra code at times, but:

  • You can see exactly what you intend to return to the user, and why.
  • If you try and return anything but a response, it’ll result in a TypeError.
  • You can test all of the different possible returns easily, by doing assertions on the returned response based on different requests provided to the handler or middleware.

But should you do everything in a handler?
What about things that will happen for whole sections of the site, or will be repeated in many locations, like initializing a session, or checking for an authenticated user, or validating headers, or caching?

For those things, PSR-15 provides middleware.
These are expected to be chained together, like a pipeline or a command bus, and the request is passed down through them, and a response returned on the way back up.
They’re a powerful way to provide re-usable pieces of functionality to your application.

What’s more, using middleware is often far easier to understand than how and when various events will intercept a request.
You can see the list of middleware for a given handler, and understand that they act either as filters on the incoming request (authentication, caching, etc.), or as decorators on the response (e.g. encoding or compressing the response, caching, etc.).
Since each does exactly one thing (ideally), you can test how each works, and understand how and when to compose each, and how they might work in combination.

Truncated by Planet PHP, read more at the original (another 865 bytes)

Advent 2023: Doctrine DBAL – Matthew Weier O’Phinney

I’ve mostly taken database abstraction for granted since I started at Zend.
We had a decent abstraction layer in ZF1, and improved it for ZF2.
There were a lot quirks to it — you really had to dive in and look at the various SQL abstraction classes to understand how to do more complex stuff — but it worked, and was always right there and available in the projects I worked on.

In the last couple of years, though, we came to the realization in the Laminas Project that we didn’t really have anybody with the expertise or time to maintain it.
We’ve marked it security-only twice now, and while we’ve managed to keep it updated to each new PHP version, it’s becoming harder and harder, and whenever there’s a CI issue, it’s anybody’s guess as to whether or not we’ll be able to get it resolved.

My alternatives have been straight PDO, or Doctrine DBAL, with the latter being my preference.

Doctrine what?

When most folks who use PHP hear “Doctrine”, they immediately think “ORM“; it’s how most folks use it, and what it’s best known for.

Underlying the ORM is its database abstraction layer (hence “DBAL”).
This library exposes an API that will work across any database it supports; this is essentially what zend-db, and later laminas-db, were doing as well.
What most folks don’t realize is that you can use the DBAL by itself, without the ORM.

Why no ORM?

ORMs are fine.
Really.
But they add an additional layer of complexity to understanding what you are actually doing.
Additionally, if you want to do something that doesn’t quite fit how the ORM works, you’ll need to drop down to the DBAL anyways.
So my take has always been: why not just use the DBAL from the beginning?

So, how does Matthew write code that interacts with the database?

I start by writing value objects that represent discrete aspects of the application.
Most of my work will be in consuming or creating these.
From there, I write a repository class that I use for purposes of persisting and retrieving them.
I can usually extract an interface from this, which aids in my testing, or if I decide I need a different approach to persistence later.

I push the work of mapping the data from the database to these objects, and vice versa, either in the repository, or in the value objects themselves (often via a named constructor).
Using these approaches creates lean code that can be easily tested, and for which there’s no real need to understand the underlying system; it’s all right there in what I’ve written for the application.

Some gripes about the documentation, and some tips

The Doctrine DBAL docs are a bit sparse, particularly when it comes to its SQL abstraction.
And there’s no “getting started” or “basic usage” guide.
In fact, it’s not until the third page within the docs that you get any code examples; thankfully, at that point they give you information on how to get a database connection:

use Doctrine\DBAL\DriverManager; $connectionParams = [ 'dbname' => 'mydb', 'user' => 'user', 'password' => 'secret', 'host' => 'localhost', 'driver' => 'pdo_mysql',
];
$conn = DriverManager::getConnection($connectionParams);

They also provide a number of other approaches, including using a DSN (an acronym they never explain, but based on using PDO, likely means “data source name”).

Once you have a connection, what do you do?
Well the DBAL connection allows you to prepare and execute queries, including via the use of prepared statements.
It provides a variety of methods for fetching individual or multiple rows, with a variety of options for how the data is returned (indexed arrays, associative arrays, individual columns, individual values, etc.).
These retrieval methods are mirrored in the result instances returned when executing prepared statements as well.

And that brings me to the SQL abstraction.

First, it’s really, really good.
It’s minimal, but it covers just about anything you need to do.
If you need to write something complex, you probably can; the beauty is that if you can’t, you can always fall back to a SQL query, and using the connection’s API for binding values.

But the documentation could be better.

It felt like it was written by a database admin who has forgotten more than most people ever learn about databases, and never considered that

Truncated by Planet PHP, read more at the original (another 7318 bytes)