Tickets tend to go up for sale a little under a year in advance and for places all around the world BUT they're all hosted in English! (yay colonialism?)
As of writing this NDC Sydney is under way with Oslo, Copenhagen, TechTown(?) and Porto neatly spaced throughout the year. Early bird prices are available up to 4-5 months before the start of the conference and are around 20% cheaper than a standard ticket.
- FOOD! (and drinks!), these are served throughout the conference. Several food stalls are setup each day with various selections from different cultures and regions (think one day will be pizza, burgers, boa buns etc..., the next day might be pasta, hot dogs etc...). Coffee is available from machines or baristas on nearly every floor.
- An NDC Hoodie - You'll get a form sent out asking for some info and your top size is one of them
- An after party - More on this later.
- Talks and workshops and the ability to speak with the presenters after the talk, you'll also find them attending other talks and generally milling about so if you don't get a chance to catch them after their talk you'll probably bump into them, or you could try contacting them through slack.
- An excellent experience - I learnt a lot and had a genuinely great time, everyone is very friendly
About 2 weeks before the start of the conference I received an email to join a slack channel where everyone attending were able to talk, several members of the NDC crew were also around in the channels and to provide assistance for any questions anyone might have had.
About 1 week before the NDC app was updated to show the agenda for the London conference. The app is handy to be able to view the talks and star the ones you want to attend, these include the floor and room you need to head to.
There's a talk about every hour with an hour free in the middle for lunch.
- DO talk to others in the chat, it's a useful way to be able to start talking to new people before you attend in person
- DON'T post messages in the room channels thinking they're "virtual rooms" for people to be able to talk - the room channels are used for each day of the conference to provide live streams of the talks in those rooms and for people to discuss and share materials related to the talks
- DO message into the "general" or "hallway" channels
- BEWARE workshops aren't recorded - Every other room is live recorded and available from the slack channels apart from the workshop room and so if you are undecided between attending a workshop or another talk, I would recommend the workshop as you can pretty easily catchup on the other talk at another time.
I opted to travel up the day before and stay in a hotel ~20 minute walk or public transit travel away which felt like a good distance to avoid paying through the nose while still being close to the venue.
It would also have been ideal for the work christmas party but the train strikes had other plans. This also made getting up to London more annoying as there were actually 0 trains running that could get me there that day (thankfully they were only partially effected for the day I was heading home).
So with this I was filled with determination that I would get to London that day and so I took... a coach! A National Express coach going from Gatwick to Victoria to be exact. I have never had the joy of taking a coach to London before, apparently there's free wifi, i'm thinking "cool, i'll get some work done on the way up"...
No, I did not manage to get any work done, the wifi refused to work for me even after having done a deal with the devil and jumping through several hoops. This was almost a blessing however as the seat width was thought of with only children in mind I think as I'm sat there folded in on myself as the lady next to me hammered away on a word document (she even had the auto-save toggle set to off, the maverick!).
~3 Hours later (what should have taken about 45 minutes) I arrive. Check-in goes relatively smoothly and after grabbing something quick for dinner and watching some TV (slow horses, it's a good watch, give it 3 episodes) I head to bed.
I didn't even realise my hotel stay included a free breakfast until I was checking in, so I headed down to find a tray of dubious looking baked beans and another of hard boiled eggs, a bowl of fruit and a cereal station, so a bowl of stale bran flakes and a banana later I head off.
First impressions "Oh rainbow corgi", shortly after "wow this place is huge!".
I head in to pass through security where they x-ray my bag (you don't need to go through the security check any other day once you arrive with your pass on) and I pick up my pass and head to pick up my hoodie, where one of the many NDC crew punched my pass to show I had collected it. The hoodies are available the whole time so I would suggest maybe picking it up at the end of the day, if you're a medium or smaller you definitely don't want to leave it too long.
The venue has a decent cloakroom that is attended to all day so you can leave your stuff there and get a ticket in return.
The expo floor and the 2 main conference rooms were on floor 3, on this floor were around a dozen stalls with lots of swag, QR codes to enter competitions and people wanting to sell you what they've produced from AWS to Okta, RavenDB and ABP.
Nearly every company was running some kind
This is the floor where the keynote talk took place to kick off NDC and was about "debugging your thinking"...
This was a vey good talk to kick off NDC, some very useful advice with my key take aways being; Slow down, write things down and ask why (5 whys) to avoid 'fixing' a solution-ised problem.
This one can be distilled down to - Terraform is good if you don't want to tie your IaC to a single cloud, bicep is good if you don't hate yourself and just want to work with azure, ARM is what is natively stored in azure and can be decompiled to bicep.
We ran out of time to talk about Pulumi which provides a way to define IaC in native programming languages like JS, C# or python. (They have since added in their own domain specific language DSL).
ToString can be very expensive; by removing a single to string a processing pipeline was able to shave 40 minutes off of a 2 hour run.
Managed instances can save money if you have had to over provision to handle spikes in traffic thanks to auto scaling instead.
Actionable observability isn't just down to storing metrics and firing off alerts on guessed thresholds but also requires teams to be trained on how to view the logs and metrics and to be able to spot when things aren't right.
Downtime isn't just when a service is dead, a slowly responding service should also be seen as down as users are likely to rage quit.
I wish this talk had more actionable advice.
Sms verification messages are a vector for attack, premium rate numbers can be spammed to farm money. Rate limits and number lookup services can be used to slow down and identify bad actors.
Git is crazy and any committed secrets are probably not secrets anymore, even if they've not been pushed remotely
AI isn't even close to being aware and can easily be tricked by reframing questions in ways it might not have been trained on
For this day I decided to just grab some breakfast from the conference center with floor 5 having a lovely selectiong of pastries and and some other types of "continental" breakfast foods along with a lovingly prepared flat white.
The doors open at 8am and the talks don't kick off until 9am so there's a good amount of time to grab some food and chill, or maybe go off an adventure and talk to some people.
Can easily be used alongside C# and can provide some nice benefits such as immutability by default. But it does require quite a paradigm shift moving to functional first programming and does require extra considerations when using F# code in a C# project.
Our monolith actually fits a lot of the suggestions recommended with a different project for each separate area. It was recommended to never share a DB; when looking to refactor the code to be more modular focus on the DB first and ensure that the data can be moved how you would need it to be, instead of starting with the code to then find the refactor isn't actually feasible the way you had architected it.
It's also possible to write architectural tests that can ensure certain code areas aren't directly referencing anything they shouldn't be e.g. domain models in the read models or function app projects.
Ask for specific feedback when raising a PR.
Avoid overwhelming a PR with lots of changes, instead start with the main feedback as the smaller changes are likely to be squashed along the way.
Don't make commands and instead ask for changes and along the same lines avoid accusational language as that is likely to get someones guard up. For example...
"You've used the wrong endpoint, use x instead"
to
"Would it be best to use Y instead of X?"
This also allows for discussion on the topic as it more open ended, there might be a good reason why your suggestion wouldn't work.
Provide examples and explain your suggestions as this is usually clearer than general feedback and provides the means to teach.
Just watch Dylan Beatties other NDC talks, they're all fun and informative - this one was definitely more philosophical than educational
Event sourcing is full of footguns, from eventual consistency, retry patterns etc... causing issues in the consuming services to being conscious of expanding events streams as they are likely to cause exponential amounts of operations as events have to be loaded and applied. Snapshots and 'Closed Books*' can help to an extent.
*End each month with an event that effectively works the same as a snapshot
Faster and more efficient than JSON based HTTP requests (REST) does require sharing a contract file (.proto) that is stored on the server and clients and used to generate the code for the communications.
Request can't be cached as only POST requests are made. Due to this even a GET is a POST where an empty request object will need to be sent.
Support any kind of streamed response you could want.
It's possible to expose a gRPC endpoint as a REST endpoint using some packages to translate the request.
Strongly typed which is nice.
Block out time and honour it.
Do you feel obligated to say yes? (i.e. you actually want to say no) - is it possible to make changes that would make it an emphatic YES, e.g. adjust dates, change scope etc... If you don't ask you wont get.
Be intentional and stick to your priorities, that includes not overburdening yourself with too many request and burning out.
Change your passwords to phrases that re-enforce what you want to believe, for example "IWillNotAgreeToEverything" the repetition is a strong way of changing your beliefs and works the same way that adverts do as exposure can change your mind.
We teach best what we need to learn - Encourage the behaviour in others.
If you like parody music then please enjoy my poorly filmed videos of Dylan Beattie and the linebreakers here - https://photos.app.goo.gl/8zxKFDEtpQ7sMuoA7
On the the Thursday is an after party where more food is available along with cocktails (including ones with 0% alcohol), beers, wines and soft drinks.
There's a couple of "after-hours" talks which are just a bit of fun more than anything.
There was also a competition with plenty of prizes up for grabs from the low rung prizes of hand sanitiser up to Sony headphones and Ember mugs. The competition was based on javascript it's many, MANY oddities.
Chat GPT is getting better but simply adding more parameters isn't getting the same kinds of results.
The use of the chat GPT models is mostly improved for more specific domains by providing examples of the materials you want it to be produce. E.G chat GPT was refined with conversational examples
avoid n-tier, clean or onion architectures (i.e. distinct layers for different types of code) and instead aim for vertical slices which is a collection of code that handles everything top to bottom.
It's ok to copy and paste 🫨it's better to have code that mostly been duplicated and edited slightly than it is to abuse an abstraction.
It's ok to have well understood abstractions that can be re-used, but these are likely to be few and far between and it's recommended to follow the rule of three.
With vertical slices it is extremely easy to follow the SRP as each vertical slice should only handle one thing.
Vertical slices also make it much easier to decompose and application in the future if the need arises (micro services).
Recommendation is to have a folder for each slice (This prevents namespace collisions for similar models)
Works well with the CQRS pattern.
Bad UIs are everywhere and usually caused by simple and unexpected reasons e.g. not enough space on a till forcing Crisps + Pickle to be a combined option.
Bad design leads to bad process which then re-enforces bad designs, I'm pretty sure we've all seen something that comes to mind when you first join a company or see a new process and you'll be thinking "Why is this being done like this" (there's probably a spreadsheet involved).
It's too easy for an interface to be designed to spec and to pass QA but the AC was fundamentally wrong or not suitable for the application.
From my personal experience McDonalds comes to mind - when people come and order food they'll start by saying "Can I get a big mac and a Chicken legend and chips and a sprite for the medium meal please?" But on the till you have to start by pressing the meal option and then selecting the choices to make up the meal - this is stupid. Why would it not work the same as when you go to shop and pickup a sandwich, crisp and drink to get a meal deal and the till works out the discount from there?
A group activity that was quite insightful, going to keep this one hush as I'd like to get engineering to take part, should only take an hour.
Moving IO to the edge of your app
A functional programming talk in disguise. Avoid having IO mixed inbetween business logic, think of how DI is used to inject services into classes, functions should have the dependent data provided to it.
Business logic should be stateless and deterministic, like pure functions - Same input = the same output.
Makes it easier to unit test as business logic is well defined and by providing string, numbers, arrays etc... to the functions and comparing the output is easy.
Use integration tests if you need to test the underlying systems to ensure the overall correctness of the system, but if the logic is correct then there should be no reasons outside of IO issues that the output shouldn't behave as expected.
A meandering tale of the languages that lead to and inspired JavaScript.
Javascript was originally going to be a lisp but the netscape execs requested it to be changed to reflect Java as that was what was hot at the time.
An optional after party that's sponsored by NDC and held in pub - makes for a good place to be able to talk with several of the speakers and other attendees.
Includes some joke presentations, including 2 where the highest rated speakers then have to perform a presentation on slide decks they haven't seen before.
It's possible to buy tickets for this without having attended NDC and there were quite a few people who had been to NDC in past or are simply friends to others who attended.