One would imagine that changing the colors of the built-in window title bar or at least painting your own custom one would be a pretty straightforward task. Sadly in Windows (more precisely Windows 10), it is not easy at all.
It took me a few tries and multiple full days of work to find a reasonable solution that is also up-to-date. Here's how it goes...
C Language provides a built-in enum type for listing types of things. The default implementation, however, leaves much to be desired. In this article I'm going to list some useful techniques I discovered working with C for the past few years.
If you have never been exposed to a language with a static type checking, it might be hard to wrap your head about what it is and how it works. One way to look at type checking is as evaluation of a secondary program that mirrors the structure but uses types as values. That sounds way more confusing than it actually is. Let me explain...
Scrollbars are one of those things you usually do not pay much attention until you need to implement one. In a very basic form, there is just some straightforward math to learn, and you are good to go. To maintain good UX you usually want to have a minimum size for the scroll grip (the thing a user can drag), which causes math to be a bit more tricky, but nothing crazy.
Real trouble begins though when you want to add marks on the scrollbar that correspond to certain positions in the document - like the ones your favorite editor shows for errors / warnings. So let's take a journey down the rabbit hole...
One of my favorite features in Haskell is "newtype". It allows you to wrap another type without any runtime overhead. Usually this is important when dealing with types that have the same underlying representation but should never be mixed together. Here is a somewhat contrived example in Haskell:
newtype Dollars = Dollars { fromDollars :: Int }
newtype Euro = Euro { fromEuro :: Int }
processEuro :: Euro -> Euro
processEuro x = x
main = do
return $ processEuro $ Dollars 3 -- type errorSince most of my day-to-day work is done in TypeScript I’m quite often tempted to use a newtype, except I couldn’t, as there was no way to define a new unique type until TypeScript 2.7 where this feature was added to support ES2015+ Symbols.
Largely due to its complicated history and implicit coercion in many places JavaScript has a lot of inconsistencies when dealing with how errors are reported from the functions and processed by the client code.
In this article, I will try to describe some of the existing strategies and will outline some new possibilities that became viable with ECMAScript 2015+ as well as things we can learn from functional programming
It’s great to see the web platform grow and get features like Service Workers, but one of the areas that traditionally gets little to no attention is dealing with user input.
While working on another project, I needed a way to insert some text at the current cursor position in a textarea to auto-complete what user is typing. It turns out this simple task is almost impossible to achieve if you want the browser to not choke on a big text inside a textarea.
"You can't touch this!" — MC Hammer
As the JavaScript matures and starts being used to build ever bigger projects, it might make sense to adapt some things that are generally accepted in the industry as best practices.
One of those things is the usage of immutable objects throughout the application. If you are familiar with Object.freeze, the solution might seem straightforward. As it happens with many things in JavaScript, there are some tricky things to keep in mind.
While making an app it is really important to keep accurate track of the versions. Usually such a tracking is implemented via tags in version control system like git. It’s also a good idea to keep in mind semantic versioning when assigning version to your code.
But tagging your code with the right version number is only the first step. You also need to show version to the user and in some cases the system.