Copyright © 2016-2018 Fantasyland Institute of Learning. All rights reserved.
A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.
val square : Int => Int = x => x * x
| scala> case class Foo(x: Int = -12345) | |
| defined class Foo | |
| scala> def y = 5 | |
| y: Int | |
| scala> val x = Foo(y) | |
| x: Foo = Foo(5) | |
| scala> val x = Foo{y} |
| package p { | |
| trait Functor[F[X]] extends Any { def fmap[A, B](x: A => B): F[A] => F[B] } | |
| trait Pointed[F[X]] extends Functor[F] { def pure[A](x: A): F[A] } | |
| trait Monad[F[X]] extends Pointed[F] { def join[A](x: F[F[A]]): F[A] } | |
| trait Copointed[F[X]] extends Functor[F] { def copure[A](x: F[A]): A } | |
| trait Comonad[F[X]] extends Copointed[F] { def cojoin[A](x: F[A]): F[F[A]] } | |
| trait Bimonad[F[X]] extends Monad[F] with Comonad[F] | |
| sealed trait Monadic[F[X], A] extends Any | |
| final case class Pure[F[X], A](x: A) extends Monadic[F, A] |
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil
| package com.scalawilliam.example.play | |
| import play.api.libs.ws._ | |
| /** | |
| * Play's Scala WS library is very very cool. Provides you with plenty niceties. | |
| * See more: https://www.playframework.com/documentation/2.3.x/ScalaWS | |
| * | |
| * Unfortunately it by default requires a Play application context. | |
| * But you do not necessarily always want that. |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
The count of contributions (summary of Pull Requests, opened issues and commits) to public repos at GitHub.com from Wed, 21 Sep 2022 till Thu, 21 Sep 2023.
Only first 1000 GitHub users according to the count of followers are taken. This is because of limitations of GitHub search. Sorting algo in pseudocode:
githubUsers
.filter(user => user.followers > 1000)
| <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | |
| xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> | |
| <modelVersion>4.0.0</modelVersion> | |
| <groupId>test</groupId> | |
| <artifactId>test</artifactId> | |
| <version>0.0.1-SNAPSHOT</version> | |
| <packaging>war</packaging> | |
| <repositories> | |
| <repository> | |
| <id>webjars</id> |
| $ mvn archetype:generate -DarchetypeCatalog=http://tapestry.apache.org/ | |
| [INFO] Scanning for projects... | |
| [INFO] | |
| [INFO] ------------------------------------------------------------------------ | |
| [INFO] Building Maven Stub Project (No POM) 1 | |
| [INFO] ------------------------------------------------------------------------ | |
| [INFO] | |
| [INFO] >>> maven-archetype-plugin:2.1:generate (default-cli) @ standalone-pom >>> | |
| [INFO] | |
| [INFO] <<< maven-archetype-plugin:2.1:generate (default-cli) @ standalone-pom <<< |
If you're building a Java web app that you yourself or your organization will be deploying then you can save yourself a lot of trouble by avoiding the whole build-to-war + deploy-to-server approach. Instead, you should build your web app as a normal Java application with an embedded web app server. Don't build a WAR, just compile the code and serve the files out of their source location. This has the following advantages:
mvn jetty:run command is being used for by many developers today.mvn jetty:run or similar to achieve a quick, iterative dev cycle. But come time for deployment, they build a WAR and throw it over the wall to be deployed in some app server