Automattic should buy Tumblr
Automattic should buy Tumblr
The DOM is designed by a committee, and it is designed to be as flexible as possible to make sure that all kinds of Web Applications can be developed. That means that the DOM is often not the easiest to use. This does not mean that the DOM sucks or anything like that. It just means that it is there to solve many different problems and use cases. And I believe that it is really good at what it attempts to do. This does not mean that front end developers should use the DOM api’s all day or ignore them.
You should probably use libraries to deal with the DOM most of the time. While at the same time do some projects where you use it directly. So that you know how it works.
When I start the day with Flogging Molly, I usually move over to Dropkick Murphy’s before lunch.
Every time I read some article or book about some new and amazing software development methodology or office / no office work system I pick up on some useful information. But the thing about all of them are that what works for your team or company depends on what you and the people you work with.
For some teams it wouldn’t matter if they were located in the same area or not, because they only talk over Slack. While others have too much “meat space” collaboration for it to work. Some people think working for home is the best. While others can’t deal with it. The perfect for me would be to do it like half of the time.
The same goes for agile. I know developers that can design and build features themselves and developers that can’t do anything unless someone give them drawing and descriptions of everything.
Pick up on the details you and your co workers like and build the mix that work for you. And hey you might get a book deal and write the next book I get annoyed at.
Every now and then I consider ditching digital photography and move over to just shooting analog.
And I think I would, if two things would happen: cheaper film and someone would start to produce mechanical SLR cameras with lenses again. Something like my Nikon FM.
Why? Because analog cameras are so much simpler. They almost never run out of batteries, and when they do I can buy new ones at a grocery store.
I know Leica still makes analog cameras, but that is a little bit too expensive for me. And I think there is room for someone to make cameras like Canon and Nikon did at the end of the 70s.
Some developers think that you should write code that can run in any browser. While others take full advantage of tools like Webpack to make it easier to build complex applications.
But then you meet another problem. Because a lot of tiny files takes much longer to load than a few big ones. But three huge files also takes longer time to load than some smaller. What you want it the perfect balance between total file size and how many files you can download at once and take full advantage of the bandwidth. And if you configure stuff correctly you’ll only download the updated parts when you update your app.
But there is one thing you should keep your eye one when you use a tool like Webpack and that is huge node modules. Because some modules from NPM may be responsible for a very large portion of the total size of the output. Just google for Webpack Bundle Analyzer to find a recent one. And start digging. The way I tackle this is to identify large modules and then I figure out if I can solve it by only importing select methods or I try to find smaller replacements. And remember to split CSS out as their own files.
I thought Pass looked interesting. So I decided to give it a shot. And it is a interesting idea. But I have decided to go back to 1Password because it is better. The user experience is much better, and pass felt too much like work. And the browser extensions was not reliable enough for me.
My girlfriend isn’t happy when I compare the local dialect to the swedish chef
The Field Notes pencil is actually good.
If you are working on a software project that have a backend or server component, it probably have some kind of configuration. Like database servers, maybe some API keys to upload to S3 etc. To get configurations right, the first time is always a pain in the ass. Because some of it is about configuring exciting tools and libraries to work with your setup, and other times it is about configuring your stuff depending on where you want to run it.
There are a few different ways you typically would deal with this. And there are a few ways I would encourage you to not do.
The biggest don’t is to not put it in a database, because you might want to take data from production and use it during development to make sure that what you make scales well. Make sure that you don’t keep settings that only works in production in the database. Because it will make stuff like testing production data much harder than it has to. And don’t just hard code settings.
The day I usually do it, is to hardcode the development settings in my projects. And then I re-configure them to run in production. Why? The less time I have to configure the machines of the people I work with, the better it is. When it comes down to the actual configuration I think there are two good ways to do it in 2018. Either with a configuration file or with environment variables. There are places where using a configuration file makes sense, and there are places where using environment variables are better. A configuration file is awesome for all kinds of settings that applies to your software project, as long as they always are the same. The moment where it might change is when you run into trouble. Because it is a pain in the ass to keep multiple almost identical files up to date. A typical software project runs in three different environment: development, staging and production. Development is a developers personal machine, staging is where you test stuff to make sure everything works in a production like environment and production is where your users or customers will use it. The way I do it these days is that everything that is not the same all places are controlled with a environment variable. Usually through a docker-compose configuration file.
What are a environment variable? Well, they are like a variable in your programming language, except that they belong to the environment the program runs in. This means that if you have two programs on written in Java and one in Python that uses the same database, they can read the same connection string.
Let’s say you have a project with two variables that change depending on where you run it: URL and DATABASE_CONNECTION_STRING. The URL is used to display the full URL to a resource for when you need it(for example when sending an e-mail) and the DATABASE_CONNECTION_STRING is used to connect to your database. I use environment variables for this because I can just change them in the script or server configuration. Instead of having to keep multiple copies of large config files on the project side of it. That someone (me) have to keep in sync. On a UNIX/Linux system you could just do something like URL=”https://yourdomain.ltd“ DATABASE_CONNECTION_STRING=“‘postgres://pompeii:pompeii@db:5432/pompeii” command-to-start-your-server to override them.
If you for some reason need to implement some project configuration on your own. Use JSON or YAML. Most if not all developers know the formats, and you’ll find parsers for all languages under the sun. And some in the shadows as well.