Pointing someone to a README.md does not lead to learning.

Solid supports templating in 3 forms JSX, Tagged Template Literals, and Solid's HyperScript variant.

Although I also work with solid in my day job at inrupt, I wrote this guide in my spare time.

I saw object proxies being the solution to doing diffing so that this approach could compete in any scenario that a VDOM could

So how do we declare the variable y to be the value of x plus 5? That's where reactive programming comes in. Reactive programming is a way of programming that makes it possible solve this problem

Here's a proxy store I wrote to derive the value of a store nested within other stores, it plays nice with typescript and can go infinitely deep

What is an iterable object in JavaScript? It’s an object that supports the iterable protocol.

no gradient tapes, no graph definitions requires

Today we begin the Early Access Program for Code With Me, a tool for remote collaborative development and pair programming that you have long been waiting for.

Indeed, this simple contract is very close to that of an ob­serv­able, such as those provided by Rxjs. set is basically equiv­a­lent to next in the ob­serv­able world.

The $ contract for auto-sub­scrib­ing is lovely in its sim­plic­ity and flex­i­bil­ity. You can adapt your own preferred state-man­age­ment pattern or library, with or without Svelte stores as helpers. Svelte does not fuss about how you want to manage your state.

However, IMO, having the conditional in the detach function is necessary, because there are other manifestations of this error. For example, if the DOM element in a component is removed from software outside of svelte, detach will have the same error.

IMO, the conditional needs to be added to detach to fix all manifestations of this error.

detach, as an api, should be declarative (ensure the node is detached) instead of imperative (detach the node), allowing it to be called multiple times by performing a noop if the node is already detached. This way, it won't matter if the node is removed from the DOM from outside of svelte.

Spending more time looking for a solution rather than thinking about it.

The benefit of this approach is that rather than having these defaults and fighting against them, it’s fully up to you to decide how to handle everything.

Then, the projects that use these libraries get to process these import statements how they like when they are bundled. For the ones that wish to load jQuery from a global, we again mark 'jquery' as an external—since we still don't want Rollup to bundle jQuery—and as a global.

I wrote hundreds of Rect components and what I learned is that Componets should be able to be styled by developer who is using it.

feel like there needs to be an easy way to style sub-components without their cooperation

The idea of a web browser being something we can comprehend, of a web page being something that more people can make, feels exciting to me.

There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.

The main reason using classes isn't a great solution is that it completely breaks encapsulation in a confusing way, the paren't shouldn't be dictating anything, the component itself should. The parent can pass things and the child can choose to use them or not but that is different: control is still in the hands of the component itself, not an arbitrary parent.

The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.

For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.

Ideally: Only let a parent control those specific CSS properties, and never let a child use them on the root element.

margin, flex, position, left, right, top, bottom, width, height, align-self, justify-self among other is CSS properties that should never be modified by the child itself. The parent should always have control of those properties, which is the whole reason I'm asking for this.

I think Svelte's approach where it replaces component instances with the component markup is vastly superior to Angular and the other frameworks. It gives the developer more control over what the DOM structure looks like at runtime—which means better performance and fewer CSS headaches, and also allows the developer to create very powerful recursive components.

Lets not extend the framework with yet another syntax

Yup.ref('value')

Often, allowing the parents to compose elements to be passed into components can offer the flexibility needed to solve this problem. If a component wants to have direct control over every aspect of a component, then it should probably own the markup as well, not just the styles. Svelte's slot API makes this possible. You can still get the benefits of abstracting certain logic, markup, and styles into a component, but, the parent can take responsibility for some of that markup, including the styling, and pass it through. This is possible today.

As you can see, this would mean that a change in a component is potentially no longer isolated to that component, and the entire codebase should be checked to see if anybody has been overriding the default styles.

Your styles are scoped to the component. No more leakage, no more unpredictable cascade.

It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.

Svelte, on the other hand, is a compiler. In a way, Svelte is more like a programming language than a library.

A paradigm is a model or pattern. In JavaScript, there are a number of popular paradigms including object-oriented programming (OOP) and functional programming (FP). Paradigms are more important than is sometimes recognized. They help form mental models for solving problems. Becoming well-versed in the principles of a given paradigm can help accelerate development by providing mental shortcuts for solving the challenges that arise while building applications. They can also help produce higher quality software.

we need to step back and make a closer look at the DRY principle. As I mentioned earlier, it stands for "Don’t Repeat Yourself" and requires that any piece of domain knowledge has a single representation in your code base. The words domain knowledge are key here. DRY is not about duplicating code. It is specifically about duplicating domain knowledge

We wanted a library designed specifically for a functional programming style, one that makes it easy to create functional pipelines, one that never mutates user data.

Hackathons are a great way of testing new technology with your team, and a place where you can go crazy with solutions.

find every email on a web page that you're on. The big kahuna - this works for every website. Inject it into a site with Chrome DevTools (more here)

var elems = document.body.getElementsByTagName("*");
var re = new RegExp("(^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$)");
for (var i = 0; i < elems.length; i++) {
    if (re.test(elems[i].innerHTML)) {
        console.log(elems[i].innerHTML);
    }
}

“I came to Rust from Haskell, and I feel that Haskell is a very elegant and safe language. The biggest differentiator for me is that there is a greater difference between high-performance code and idiomatic ‘clean’ code in Haskell than in Rust. Most Rust code looks like most other Rust code, even when it performs well. Haskell can become unfamiliar real quick if someone is operating under different libraries and goals from what you are typically doing. Small differences in syntax can result in huge differences in behavior, and Rust has more uniformity on that axis.”

Then when giving answers I'm even less certain. For example I see occasional how-to questions which (IMO) are ridiculously complex in bash, awk, sed, etc. but trivial in python, (<10 lines, no non-standard libraries). On such questions I wait and see if other answers are forthcoming. But if they get no answers, I'm not sure if I should give my 10 lines of python or not.

Go cheatsheet

The above errors can be resolved by simply adding the ⚡attribute to the <html> tag like so: <html ⚡ lang="en">

<html ⚡>

⚡4email

TLA+ is a high-level language for modeling programs and systems--especially concurrent and distributed ones.

Essays on programming I think about a lot

Introducing Module#const_source_locationUsing Method#source_location made finding the location of any method fairly easy. Unfortunately, there wasn’t an equivalent for constants. This meant that unless the constant you needed to find was defined in your codebase, finding its source location was not easy.

When FrozenError is raised, it is usually difficult to determine from the context which was the frozen object that a modification was attempted on.Ruby 2.7 introduces FrozenError#receiver which will return the frozen object that modification was attempted on, similar to NameError#receiver. This can help pinpoint exactly what is the frozen object.

A beginless range is experimentally introduced. It might not be as useful as an endless range, but would be good for DSL purposes.

dynamic

multi-paradigm

the overloaded operators ¬, =, ≠, and abs are defined

Most of Algol's "special" characters (⊂, ≡, ␣, ×, ÷, ≤, ≥, ≠, ¬, ⊃, ≡, ∨, ∧, →, ↓, ↑, ⌊, ⌈, ⎩, ⎧, ⊥, ⏨, ¢, ○ and □) can be found on the IBM 2741 keyboard with the APL "golf-ball" print head inserted; these became available in the mid-1960s while ALGOL 68 was being drafted. These characters are also part of the Unicode standard and most of them are available in several popular fonts.

Typical software requirements specify the following

The brain uses the same area to save coding as it does to save our speech. They found that programming is like talking. The research found out that the brain regions that are most active during coding are those that are also relevant in the processing of natural language.

in Python - setting up basic logger is very simple

import logging
logging.basicConfig(
    filename='application.log',
    level=logging.WARNING,
    format= '[%(asctime)s] {%(pathname)s:%(lineno)d} %(levelname)s - %(message)s',
    datefmt='%H:%M:%S'
)

logging.error("Some serious error occurred.")
logging.warning('Function you are using is deprecated.')

[12:52:35] {<stdin>:1} ERROR - Some serious error occurred.
[12:52:35] {<stdin>:1} WARNING - Function you are using is deprecated.

logging.getLoggerClass().root.handlers[0].baseFilename

- High-level modules should not depend on low-level modules. Both should depend on the abstraction.- Abstractions should not depend on details. Details should depend on abstractions.

Clients should not be forced to depend on methods that they do not use.

If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.

Classes should be open for extension, but closed for modification

A class should have a single responsibility

This tightly controlled build environment is sometimes called a "holy build box". The Traveling Ruby project provides such a holy build box.

Don’t go to code academy, go to design academy. Be advocates of the user & consumer. It’s not about learning how to code, it’s about translating real-world needs to technological specifications in just ways that give end users agency and equity in design, development and delivery. Be a champion of user-centric design. Learn how to steward data and offer your help.

function (or in the case of type classes, we call these methods)

If you can tell that two types are equal or not equal, that type belongs in the Eq type class.

Continuous Delivery of Deployment is about running as thorough checks as you can to catch issues on your code. Completeness of the checks is the most important factor. It is usually measured in terms code coverage or functional coverage of your tests. Catching errors early on prevents broken code to get deployed to any environment and saves the precious time of your test team.

Continuous Integration is a trade off between speed of feedback loop to developers and relevance of the checks your perform (build and test). No code that would impede the team progress should make it to the main branch.

A good CD build: Ensures that as many features as possible are working properly The faster the better, but it is not a matter of speed. A 30-60 minutes build is OK

A good CI build: Ensures no code that breaks basic stuff and prevents other team members to work is introduced to the main branch Is fast enough to provide feedback to developers within minutes to prevent context switching between tasks

The idea of Continuous Delivery is to prepare artefacts as close as possible from what you want to run in your environment. These can be jar or war files if you are working with Java, executables if you are working with .NET. These can also be folders of transpiled JS code or even Docker containers, whatever makes deploy shorter (i.e. you have pre built in advance as much as you can).

Continuous Delivery is about being able to deploy any version of your code at all times. In practice it means the last or pre last version of your code.

Continuous Integration is not about tools. It is about working in small chunks and integrating your new code to the main branch and pulling frequently.

The app should build and start Most critical features should be functional at all times (user signup/login journey and key business features) Common layers of the application that all the developers rely on, should be stable. This means unit tests on those parts.

Continuous Integration is all about preventing the main branch of being broken so your team is not stuck. That’s it. It is not about having all your tests green all the time and the main branch deployable to production at every commit.

// ES5-compatible code var myObject = { prop1: 'hello', prop2: 'world', output: function() { console.log(this.prop1 + ' ' + this.prop2); } }; myObject.output(); // hello world

Scrum means that “you have to get certain things done with those two weeks.” Kanban means “do what you can do in two weeks.”

What people will say is that estimates are for planning – that their purpose is to figure out how long some piece of work is going to take, so that everybody can plan accordingly. In all my five years shipping stuff, I can only recall one project where things really worked that way.

Be explicit about the difference between hard deadlines

If you delegate all your IT security to the InfoSec, they will come up with draconian rules

you should always advocate for having a dedicated SRE if there’s any real risk of after-hours pages that are out of your control.

I try to write a unit test any time the expected value of a defect is non-trivial.

I’m defining an integration test as a test where you’re calling code that you don’t own

Which database technology to choose

I would use a serverless function when I have a relatively small and simple chunk of code that needs to run every once in a while.

Programming languages These will probably expose my ignorance pretty nicely.

A few takeaways

I set it with a few clicks at Travis CI, and by creating a .travis.yml file in the repo

language: node_js
node_js: node

before_script:
  - npm install -g typescript
  - npm install codecov -g

script:
  - yarn lint
  - yarn build
  - yarn test
  - yarn build-docs

after_success:
  - codecov

I set it with a few clicks at Travis CI, and by creating a .travis.yml file in the repo

language: node_js
node_js: node

before_script:
  - npm install -g typescript
  - npm install codecov -g

script:
  - yarn lint
  - yarn build
  - yarn test
  - yarn build-docs

after_success:
  - codecov

Continuous integration makes it easy to check against cases when the code: does not work (but someone didn’t test it and pushed haphazardly), does work only locally, as it is based on local installations, does work only locally, as not all files were committed.

In Python, when trying to do a dubious operation, you get an error pretty soon. In JavaScript… an undefined can fly through a few layers of abstraction, causing an error in a seemingly unrelated piece of code.

function add(a,b) { return + (a + b) }
add(2,2)
add('2', 2)

With Codecov it is easy to make jest & Travis CI generate one more thing:

I would use ESLint in full strength, tests for some (especially end-to-end, to make sure a commit does not make project crash), and add continuous integration.

It is fine to start adding tests gradually, by adding a few tests to things that are the most difficult (ones you need to keep fingers crossed so they work) or most critical (simple but with many other dependent components).

I found that the overhead to use types in TypeScript is minimal (if any).

I need to specify types of input and output. But then I get speedup due to autocompletion, hints, and linting if for any reason I make a mistake.

TSDoc is a way of writing TypeScript comments where they’re linked to a particular function, class or method (like Python docstrings).

ESLint does automatic code linting

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Write a new test and the result. If you want to make it REPL-like, instead of writing console.log(x.toString()) use expect(x.toString()).toBe('') and you will directly get the result.

interactive notebooks fall short when you want to write bigger, maintainable code

I recommend Airbnb style JavaScript style guide and Airbnb TypeScript)

Creating meticulous tests before exploring the data is a big mistake, and will result in a well-crafted garbage-in, garbage-out pipeline. We need an environment flexible enough to encourage experiments, especially in the initial place.

The programming language is augmented with natural language description details, where convenient, or with compact mathematical notation.

There are many types of CRDTs

Some of our main takeaways:CRDT literature can be relevant even if you're not creating a decentralized systemMultiplayer for a visual editor like ours wasn't as intimidating as we thoughtTaking time to research and prototype in the beginning really paid off

traditional approaches that informed ours — OTs and CRDTs

CRDTs refer to a collection of different data structures commonly used in distributed systems. All CRDTs satisfy certain mathematical properties which guarantee eventual consistency. If no more updates are made, eventually everyone accessing the data structure will see the same thing. This constraint is required for correctness; we cannot allow two clients editing the same Figma document to diverge and never converge again

They’re a great way of editing long text documents with low memory and performance overhead, but they are very complicated and hard to implement correctly

Even if you have a client-server setup, CRDTs are still worth researching because they provide a well-studied, solid foundation to start with

Figma’s multiplayer servers keep track of the latest value that any client has sent for a given property on a given object

Figma doesn’t store any properties of deleted objects on the server. That data is instead stored in the undo buffer of the client that performed the delete. If that client wants to undo the delete, then it’s also responsible for restoring all properties of the deleted objects. This helps keep long-lived documents from continuing to grow in size as they are edited

it's important to be able to iterate quickly and experiment before committing to an approach. That's why we first created a prototype environment to test our ideas instead of working in the real codebase

Designers worried that live collaborative editing would result in “hovering art directors” and “design by committee” catastrophes.

We had a lot of trouble until we settled on a principle to help guide us: if you undo a lot, copy something, and redo back to the present (a common operation), the document should not change. This may seem obvious but the single-player implementation of redo means “put back what I did” which may end up overwriting what other people did next if you’re not careful. This is why in Figma an undo operation modifies redo history at the time of the undo, and likewise a redo operation modifies undo history at the time of the redo

operational transforms (a.k.a. OTs), the standard multiplayer algorithm popularized by apps like Google Docs. As a startup we value the ability to ship features quickly, and OTs were unnecessarily complex for our problem space

Every Figma document is a tree of objects, similar to the HTML DOM. There is a single root object that represents the entire document. Underneath the root object are page objects, and underneath each page object is a hierarchy of objects representing the contents of the page. This tree is is presented in the layers panel on the left-hand side of the Figma editor.

When a document is opened, the client starts by downloading a copy of the file. From that point on, updates to that document in both directions are synced over the WebSocket connection. Figma lets you go offline for an arbitrary amount of time and continue editing. When you come back online, the client downloads a fresh copy of the document, reapplies any offline edits on top of this latest state, and then continues syncing updates over a new WebSocket connection

An important consequence of this is that changes are atomic at the property value boundary. The eventually consistent value for a given property is always a value sent by one of the clients. This is why simultaneous editing of the same text value doesn’t work in Figma. If the text value is B and someone changes it to AB at the same time as someone else changes it to BC, the end result will be either AB or BC but never ABC

We use a client/server architecture where Figma clients are web pages that talk with a cluster of servers over WebSockets. Our servers currently spin up a separate process for each multiplayer document which everyone editing that document connects to

Sometimes it's interesting to explain some code (How many time you spend trying to figure out a regex pattern when you see one?), but, in 99% of the time, comments could be avoided.

When we talk about abstraction levels, we can classify the code in 3 levels: high: getAdress medium: inactiveUsers = Users.findInactives low: .split(" ")

The ideal is not to mix the abstraction levels in only one function.

There is another maxim also that says: you must write the same code a maximum of 3 times. The third time you should consider refactoring and reducing duplication

Should be nouns, and not verbs, because classes represent concrete objects

Uncle Bob, in clean code, defends that the best order to write code is: Write unit tests. Create code that works. Refactor to clean the code.

int d could be int days

naming things, write better functions and a little about comments. Next, I intend to talk about formatting, objects and data structures, how to handle with errors, about boundaries (how to deal with another's one code), unit testing and how to organize your class better. I know that it'll be missing an important topic about code smells

Should be verbs, and not nouns, because methods represent actions that objects must do

decrease the switch/if/else is to use polymorphism

In the ideal world, they should be 1 or 2 levels of indentation

"The Big Picture" is one of those things that people say a whole lot but can mean so many different things. Going through all of these articles, they tend to mean any (or all) of these things

Considering that there are still a ton of COBOL jobs out there, there is no particular technology that you need to know

read Knuth, or Pragmatic Programming, or Clean Code, or some other popular book

Senior developers are more cautious, thoughtful, pragmatic, practical and simple in their approaches to solving problems.

In recent years we’ve also begun to see increasing interest in exploratory testing as an important part of the agile toolbox

When I began coding, around 30 years ago, waterfall software development was used nearly exclusively.

Mathematica didn’t really help me build anything useful, because I couldn’t distribute my code or applications to colleagues (unless they spent thousands of dollars for a Mathematica license to use it), and I couldn’t easily create web applications for people to access from the browser. In addition, I found my Mathematica code would often end up much slower and more memory hungry than code I wrote in other languages.

In the 1990s, however, things started to change. Agile development became popular. People started to understand the reality that most software development is an iterative process

a methodology that combines a programming language with a documentation language, thereby making programs more robust, more portable, more easily maintained, and arguably more fun to write than programs that are written only in a high-level language. The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer.

Developing in the cloud

Finding a database management system that works for you

Here are a few very prominent technologies that you can look into and what impact each one might have on your salary

What programming language should I learn next?

Android and iOS

First, you’ve spread the logic across a variety of different systems, so it becomes more difficult to reason about the application as a whole. Second, more importantly, the logic has been implemented as configuration as opposed to code. The logic is constrained by the ability of the applications which have been wired together, but it’s still there.