SeasonedDev
335 subscribers
49 photos
91 links
Take your coding skills to the next level,- programming notes, tutorials, quizzes, and tips!

Fullstack, Web, Frontend, JavaScript, React, Software, Architecture, SQL, Books, Mentoring, Interview, Jobs

Chat: @webdev_en

Created by: @wojiaomakeximu
Download Telegram
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
๐ŸŽ ๐ŸŽ„๐ŸŽ‰
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, gql and graphql_tools.

I also show you to setup http server, and deno_mongo for connecting to a MongoDB instance: https://youtu.be/BS0tq9dtr7Y

A README page & source code for the video are on GitHub.

#deno #graphql #mongo
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
โ€‹โ€‹๐Ÿ’ฌ 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.
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
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.
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.
GitHub lists (Beta)

Did you know you can create your own lists for starred repositories?

I don't have much fantasy so I've only created a few: My projects and Curated list (for materials).

Any other idea how this feature could be helpful?
โ€‹โ€‹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:
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)
โ€‹โ€‹If you ever need to extract data from an HTML page, you would probably start with using the browser console, 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.
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
What would be the output? Check yourself here.
Well, I used to develop with Angular (AngularJS, 2+) for years, then I switched to React and, truth be told... I am not going to coming back. And, according to the graph, it seems I'm not alone in this ๐Ÿ™‚

p.s. Btw, I liked Vue as well, I'm just not sure if it's production ready