Such an interesting survey to share, if you'd like to stay up to date on the trends: https://jamstack.org/survey/2021/
Even if you're not familiar with the Jamstack, some of these slides can be really curious.
Another massive survey by stackoverflow was in May 2021 and can be found here: https://insights.stackoverflow.com/survey/2021
Even if you're not familiar with the Jamstack, some of these slides can be really curious.
Another massive survey by stackoverflow was in May 2021 and can be found here: https://insights.stackoverflow.com/survey/2021
Hi guys, the first video in this year is about building a GraphQL Server with Deno and MongoDB Atlas.
Learn how to setup a GraphQL Server from scratch using Deno,
I also show you to setup http server, and
A README page & source code for the video are on GitHub.
#deno #graphql #mongo
Learn how to setup a GraphQL Server from scratch using Deno,
gql and graphql_tools.I also show you to setup http server, and
deno_mongo for connecting to a MongoDB instance: https://youtu.be/BS0tq9dtr7YA README page & source code for the video are on GitHub.
#deno #graphql #mongo
YouTube
Build a GraphQL Server with Deno and MongoDB Atlas
Build a GraphQL Server with Deno and MongoDB Atlas tutorial. Learn how to setup a GraphQL Server from scratch using Deno, gql and graphql_tools. I also show you to setup http server, and deno_mongo for connecting to a MongoDB instance.
00:00 Deno, graphql…
00:00 Deno, graphql…
Hi guys, working with environment variables is a great way to configure your Deno application.
This video is a quick tutorial to setting up your Deno project using environment variables and storing configuration data in .env files.
A README page & source code for the video are on GitHub.
#deno #dotenv #environmentvariables
This video is a quick tutorial to setting up your Deno project using environment variables and storing configuration data in .env files.
A README page & source code for the video are on GitHub.
#deno #dotenv #environmentvariables
YouTube
Setup Environment Variables for Deno, a BEGINNER FRIENDLY Dotenv Tutorial
Working with environment variables is a great way to configure your Deno application. This video is a quick tutorial to setting up your Deno project using environment variables and storing configuration data in .env files. I'll show you how to set environment…
💬 Here is another brilliant note from the 'The Pragmatic Programmer' book.
Educated guess vs Fortune telling
TL;DR. Instead of wasting effort designing for an uncertain future, you should design your code to be replaceable.
> Don't outrun your headlights
In software development our headlights are limited, we can't see too far ahead into the future.
> Take small steps - always
Always take small, deliberate steps, checking for feedback and adjusting before proceeding.
Try to stick educated guess, not fortune telling / wild speculation.
You can find yourself fortune telling when you have to:
- Estimate completion dates in months
- Plan a design for future maintain/extend-abilities
- Guess user's future needs
- Guess future tech availability
But how are we supposed to design future maintenance? Only as far ahead as you can see.
🔥 Instead of wasting effort designing for an uncertain future, you should design your code to be replaceable.
Making code replaceable will also help with cohesion, decoupling, and DRY, leading to a better design overall.
And at the end of the day, there's always the chance for a black swan around the corner.
Educated guess vs Fortune telling
TL;DR. Instead of wasting effort designing for an uncertain future, you should design your code to be replaceable.
> Don't outrun your headlights
In software development our headlights are limited, we can't see too far ahead into the future.
> Take small steps - always
Always take small, deliberate steps, checking for feedback and adjusting before proceeding.
Try to stick educated guess, not fortune telling / wild speculation.
You can find yourself fortune telling when you have to:
- Estimate completion dates in months
- Plan a design for future maintain/extend-abilities
- Guess user's future needs
- Guess future tech availability
But how are we supposed to design future maintenance? Only as far ahead as you can see.
🔥 Instead of wasting effort designing for an uncertain future, you should design your code to be replaceable.
Making code replaceable will also help with cohesion, decoupling, and DRY, leading to a better design overall.
And at the end of the day, there's always the chance for a black swan around the corner.
This video is a short reminder about importance of resource management.
Last time I showed you how to connect a Deno app to a MongoDB Atlas instance. This time I'll show you what happens if you don't manage your resource properly, how to troubleshoot potential issues, and what to do to release the allocated resources.
#deno #nodejs #programming
Last time I showed you how to connect a Deno app to a MongoDB Atlas instance. This time I'll show you what happens if you don't manage your resource properly, how to troubleshoot potential issues, and what to do to release the allocated resources.
#deno #nodejs #programming
YouTube
What Happens When You Don't Release Allocated Resources. Avoiding Leaks in Deno, Node.js, Everywhere
This video is a short reminder about importance of resource management. Last time I showed you how to connect a Deno app to a MongoDB Atlas instance. This ti...
Hi guys, here is a quick note with code examples about the TDA (Tell, Don't Ask) principle.
In short, instead of asking an object for data and acting on that data, you should tell an object what to do.
The code examples are great, if only in the OO world though.
In short, instead of asking an object for data and acting on that data, you should tell an object what to do.
The code examples are great, if only in the OO world though.
I didn't know that there is the https://reactivex.io website, that defines a language-agnostic set of principles and documents some common implementations.
It has the introduction, docs, and tons of tutorials. Check this out if the Reactive approach is in your list of skills to learn.
It has the introduction, docs, and tons of tutorials. Check this out if the Reactive approach is in your list of skills to learn.
Actors and Processes
One of the ways to implement concurrency without the pain of synchronizing access to shared memory is to use actors.
▫️An actor is an independent processor with its own local (and private) state. Each actor listens to his 'mailbox' and process appearing messages. If the mailbox is empty, it goes to sleep.
A few notes about this approach:
▫️Nothing schedules what happens next, or orchestrates the workflow
▫️The only state in the system is held in messages and in the local (and private) state of each actor
▫️All messages are one way (no replying). If you want an actor to return a response, you include your own mailbox address in the message, and it will (eventually) send the response as just another message to that mailbox
▫️An actor processes each message to completion, and only one message at a time
As a result, actors execute concurrently, asynchronously, and share nothing.
✨ Use actors for concurrency without shared state
Three actors to implement a diner scenario: the customer, the waiter, and the pie case.
The overall message flow:
🔸 We tell the customer that they are hungry
🔸 In response, they'll ask the waiter for pie:
🔸 The waiter will ask the pie case to get some pie to the customer:
🔸 If the pie case has a slice available, it will send it to the customer and notify the waiter to add it to the bill:
In the actor model, there's no need to write any code to handle concurrency. There's also no need to orchestrate like 'do this, do that'. The actors work it out for themselves based on the messages they receive.
References:
- The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition)
One of the ways to implement concurrency without the pain of synchronizing access to shared memory is to use actors.
▫️An actor is an independent processor with its own local (and private) state. Each actor listens to his 'mailbox' and process appearing messages. If the mailbox is empty, it goes to sleep.
A few notes about this approach:
▫️Nothing schedules what happens next, or orchestrates the workflow
▫️The only state in the system is held in messages and in the local (and private) state of each actor
▫️All messages are one way (no replying). If you want an actor to return a response, you include your own mailbox address in the message, and it will (eventually) send the response as just another message to that mailbox
▫️An actor processes each message to completion, and only one message at a time
As a result, actors execute concurrently, asynchronously, and share nothing.
✨ Use actors for concurrency without shared state
Three actors to implement a diner scenario: the customer, the waiter, and the pie case.
The overall message flow:
🔸 We tell the customer that they are hungry
🔸 In response, they'll ask the waiter for pie:
dispatch(state.waiter, { type: 'order' }, customer: self)🔸 The waiter will ask the pie case to get some pie to the customer:
dispatch(state.pieCase, { type: 'get slice' }, customer: msg.customer, waiter: self)🔸 If the pie case has a slice available, it will send it to the customer and notify the waiter to add it to the bill:
dispatch(msg.customer, { type: 'put on the table' })dispatch(msg.waiter, { type: 'add to order' }, customer: msg.customer)In the actor model, there's no need to write any code to handle concurrency. There's also no need to orchestrate like 'do this, do that'. The actors work it out for themselves based on the messages they receive.
References:
- The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition)
📝 Refactoring: When, Why, How
TL;DR. Refactor early, refactor often
When should you refactor your code?
You refactor when you've learned something new, when you understand something better than you did before.
It's time to refactor if there is:
🔸 Duplication- violation of the DRY principle
🔸 Outdated knowledge- requirements change, code needs to keep up
🔸 Usage- based on the real users feedback
🔸 Performance bottlenecks
Why should you refactor?
Time pressure is often used as an excuse for not refactoring. But this is wrong. The longer you wait, the more time investments you'll need. There won't be more time available.
✨ If refactoring is a surgery operation, then you want to remove something that's growing sooner than later. You can go in now, and take it out while it's still small. Wait too long, and you may lose the patient.
How to refactor?
A few tips from Martin Fowler:
🔸 Don't try to refactor and add functionality at the same time
🔸 Make sure you have good tests before you begin refactoring
🔸 Take short, deliberate steps. If you keep them small, and test after each step, you'll avoid prolonged debugging
References:
The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition)
TL;DR. Refactor early, refactor often
When should you refactor your code?
You refactor when you've learned something new, when you understand something better than you did before.
It's time to refactor if there is:
🔸 Duplication- violation of the DRY principle
🔸 Outdated knowledge- requirements change, code needs to keep up
🔸 Usage- based on the real users feedback
🔸 Performance bottlenecks
Why should you refactor?
Time pressure is often used as an excuse for not refactoring. But this is wrong. The longer you wait, the more time investments you'll need. There won't be more time available.
✨ If refactoring is a surgery operation, then you want to remove something that's growing sooner than later. You can go in now, and take it out while it's still small. Wait too long, and you may lose the patient.
How to refactor?
A few tips from Martin Fowler:
🔸 Don't try to refactor and add functionality at the same time
🔸 Make sure you have good tests before you begin refactoring
🔸 Take short, deliberate steps. If you keep them small, and test after each step, you'll avoid prolonged debugging
References:
The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition)
If you ever need to extract data from an HTML page, you would probably start with using the browser console,
Next, you'd be good if you are going to use it as a part of a Chrome/FF extension. However, most of you, will probably try to adopt it with NodeJS. And here is the thing- it could be time consuming asf.
Your first choice? Puppeteer. Bad idea- you'll have to forget about your beautiful browser code and start using tons of puppeteer specific methods like
JSDOM is something that comes next. Looks good, as long as all you need is to just query for HTML structure. But, you'll probably wanna get some data with
Cheerio- if you google for nodejs html parse tutorial, you'll see a lot of mentions of this package. But the API is pretty jQuery style (
✨ Long story short, after all of these unsuccessful tries, I ended up using a beautiful node-html-parser package. It's not popular but super fast and you know what? You'll only need minor changes to your browser parsing code. I'll add the examples.
Take care, guys!
document.querySelector, and CSS/XPath selectors (like we did in the youtube video about parsing google maps).Next, you'd be good if you are going to use it as a part of a Chrome/FF extension. However, most of you, will probably try to adopt it with NodeJS. And here is the thing- it could be time consuming asf.
Your first choice? Puppeteer. Bad idea- you'll have to forget about your beautiful browser code and start using tons of puppeteer specific methods like
evaluate, $$eval, and others. No outside functions will be accessible from the execution context, and even if you pass them as an argument, you'll get just an empty object. And even if you make it work, at the end of the day you'll get a terrible library lock.JSDOM is something that comes next. Looks good, as long as all you need is to just query for HTML structure. But, you'll probably wanna get some data with
innerText or innerHTML, right? There is a feature request created on Sep, 2015 and 7 years later is still not implemented. So don't use JSDOM if you're looking for data extraction.Cheerio- if you google for nodejs html parse tutorial, you'll see a lot of mentions of this package. But the API is pretty jQuery style (
$('.apple', '#fruits').text()), so, again, the code you've written in the browser won't work without significant changes.✨ Long story short, after all of these unsuccessful tries, I ended up using a beautiful node-html-parser package. It's not popular but super fast and you know what? You'll only need minor changes to your browser parsing code. I'll add the examples.
Take care, guys!
If you can only read one programming book this year, I hope it will be 'The Pragmatic Programmer, 20th anniversary edition'. ❤️
💬 Clean Architecture, A Craftsman's Guide to Software Structure and Design by Robert C. Martin is my biggest disappointment of 2022 so far.
His series of "Clean" books is quite popular and recognized in IT field. However, it seems that the Clean Architecture book was not written to be read, but to be sold.
The meaningful part of the book includes about 370 pages, 50 of which are 'architecture archaeology' ("In the late 1960s, a company by the name of ASC Tabulating signed a contract with..." and other dad's noises).
Okay, 320 pages of a good book is still good, right? Well, the guy seems to be obsessed with the "The best code is the code you don't write" principle, so about 65 pages are literally blank pages and chapter illustrations. What could be better than adding 34 chapters, so you can add 34 blank and 34 pages of irrelevant illustrations.
There are still about 250 pages left to hold the wisdom of the art of designing clean architecture, right? Well, I don't want to upset you but the rest of the book is about SOLID principles and how to apply them to various parts of software architecture.
There are almost no references to messaging or events. Microservices and SOA are barely explained, no mentioning about CQRS or Event Sourcing. The book lacks of real practical examples, the pros and cons of various solutions are completely missing.
Most of it is just "Use interfaces to hide implementation details." and "don't do coupling", "don't do coupling in your database", "don't do coupling in your services", "don't do coupling in your web frontend".
I hope I saved you some time and money.
His series of "Clean" books is quite popular and recognized in IT field. However, it seems that the Clean Architecture book was not written to be read, but to be sold.
The meaningful part of the book includes about 370 pages, 50 of which are 'architecture archaeology' ("In the late 1960s, a company by the name of ASC Tabulating signed a contract with..." and other dad's noises).
Okay, 320 pages of a good book is still good, right? Well, the guy seems to be obsessed with the "The best code is the code you don't write" principle, so about 65 pages are literally blank pages and chapter illustrations. What could be better than adding 34 chapters, so you can add 34 blank and 34 pages of irrelevant illustrations.
There are still about 250 pages left to hold the wisdom of the art of designing clean architecture, right? Well, I don't want to upset you but the rest of the book is about SOLID principles and how to apply them to various parts of software architecture.
There are almost no references to messaging or events. Microservices and SOA are barely explained, no mentioning about CQRS or Event Sourcing. The book lacks of real practical examples, the pros and cons of various solutions are completely missing.
Most of it is just "Use interfaces to hide implementation details." and "don't do coupling", "don't do coupling in your database", "don't do coupling in your services", "don't do coupling in your web frontend".
I hope I saved you some time and money.
I like this explanation how JWT (JSON Web Tokens) works.
Read more about private, public key validation. https://en.wikipedia.org/wiki/Public-key_cryptography
Read more about private, public key validation. https://en.wikipedia.org/wiki/Public-key_cryptography