Application Development Meanderings

programming languages, not sure javascript's ES* all make sense Well I was just thinking the other day about javascript and its pros and cons. Its clearly an interpreted language with a simple syntax. That makes it easy to learn. However, there have been alot of changes using the ES* process. Each version adds some new functionality, sometimes a little sometimes alot. Sometimes just enhancing a few APIs sometimes making large changes, such as adding module systems. I was doing some work in scala.js the other day, along with nodejs+express+mssql+typescript for the backend. I could have written the backend in scala.jvm but there was no compelling reason to do that as there was some json manipulation and I find js to be easier to use when json is involved. You can avoid alot of encoders/decoder type coding when using scala.js and that just makes it much easier (whether you are in scala.js or typescript). But I did notice that even with instant node+express rel...

env variables with node, express and typescript If you need to manage environment variables better for express, node and typescript web services, you have a few choices. Define a default set of vars using an “environments” file and fallback to those while using an optional user provided file. Add fallback values in .ts code. Don’t add fallback values and error out of require variables are missing. The standard thinking is that if you have environment variables that hold secrets or a file of environment variables these should not be checked in at all because you should use the production method of setting environment variables e.g. a container can set environment variables using container methods. You can always setup a separate, restricted VCS repo to hold secrete information that only production admins can access. Hence, .env files should only be used for non-production, say dev and test, and not checked into VSC. The default package to use is “dotenv”. dot...

typescript, node, express: adding ts properties to Request If you use typescript with node+express and you add some context to the Request parameters, you need to adjust your Request type to reflect the additional properties. Otherwise, your IDE may flag any accesses to these properties as errors. Let’s assume you will add an “environment” property to Request. You’ll want to have that property available to typescript. I always have a types folder sitting around in my “src” directory that has a types.d.ts file. You do not need to put this into a type roots folder and change tsconfig.json. Here’s my adjusment: import { Request , Response , Send } from "express" import * as env from "../interfaces/Environment" // add our addition to Request declare global { namespace Express { interface Request { environment : env . Environment } interface Response { // holds original Response.sense, used...

quick note on scala.js, react hooks, monix, auth Reactjs hooks finally came out of preview in a recent version of React. scalajs-reaction has had support for hooks since they were in preview. React hooks seem like the hot new thing but for me the question is, do hooks help improve your code by improving maintainability, time to market, TCO, etc.? Let’s take a look using authentication as an example and employ monix , a reactive observable framework that also builds on cats . We will assume we are building a SPA. Does it improve your code and make your application & development experience better? Auth Auth processing can be complex. Many react auth examples you find in blogs like to show how to use “react-routing” and “auth” as a switch that determines which routes are protected or unprotected. Protected routes show application specific data. Unprotected routes show login content . Based on storing a “User” object in the browser session/local storage, th...

scala, kotlin, javascript, swift, dart, ... This is a short note on programming languages (PL). In general, I do not really care about the PL as long as it is reasonably succinct and capable to solve the problem at hand. Ideally, one PL can be used to solve different problems to amortize the cost of learning a PL over multiple projects. Lately, everyone has defined their own programming language associated with their “platform.” Apple has Swift, google has dart (but uses java/js for other frameworks/platforms), Microsoft has C#, Sun had java, jetbrains has Kotlin. Some companies push their language as multi-platform, like Sun did, others evolve their PL to be multi-platform. The whole PL situation is a mess. Each language is much like the other. More or less C-like with some PLs having a few more clever features than others. A company defines their own PL to control their destiny and ensure they are not dependent on another organization to evolve their platform....

Ok, I think John was right about IO bifunctor.. A while ago there a post on how IO in scalaz had both a F and an E to reflect the error type that is more specific than Throwable . Cat has MonadError and ApplicativeError that assumes the error is a Throwable . That has alot of implications all up and down the APIs. Just as F has to be everywhere, once you want to customize the error to be more specific than Throwable or not related to Throwable at all much like as described in https://typelevel.org/blog/2018/11/28/http4s-error-handling-mtl-2.html , you have to fix all the APIs all the way down. That means the post http://degoes.net/articles/bifunctor-io from John was kind of right in my eyes. Once you do the work to be anything more specific, you might as well be explicit everywhere since one the flood gates open, that’s it. You can always be less specific. I ran into this issue when creating some specialized scala HTTP client’s that have a wide variety of...

zio and scalatest If you use scalatest with zio , you need to recognize that there are a few ways to hook up scalatest. In the end, the problem is that scalatest uses exceptions to signal failure and that does not really work well with a library that models errors explicitly (or fp in general which treats errors as values). Some notes: scalatest has two async-test error channels–throwing an exception in open code and putting an exception into a Future . You can throw an exception or return an Assertion . The Assertion can be true or not true. However, a failed Assertion really just throws a TestFailedException immediately there is no “failed” Assertion value. You can get about as much debugging information from throwing an exception as you do an Assertion if you convert the zio Cause to a string. You can run async tests but you need to return a Future[Assertion]. I wanted to keep everything async so I could run this in JS when that’s available for zio. scala...