129 karma · joined January 9, 2011
Nothing fancy, just a web server getting file and saving them. Like a KV-storage.
I have deployed it to dogital ocean on 2017. I have not TOUCHED it since then. Still running good. And I can access the Pharo GUI via the web VNC just from my browser with full access to the IDE and dev env.
The cons: I forgot how to run that docker image. If it fails I am in troubles reminding myself how to run it one more time. 6 years have passed...
So I decided to document main flows and designs in PlantUML diagrams. having these diagrams greatly improved onboarding process, cause you can quickly glance what component does what and what are the dependencies (the code base was in JS, so it is usually quite limited on refactoring/figuring out wtf is going on).
But the problem with such approach is: diagram quickly gets out of date. Someone makes the change and the diagram makes no sense at all now. With what I saw in Gtoolkit, you can always query the real source code and build custom dev tools that always produce current and real overview of the system. I would love to have a starter kit for JS projects that you can drag and drop and start building your own tooling for your product.
Settlers V was naahhh and their latest browser based game was a disappointment as well.
Instead of waiting on normal settlers I decided to build my own game: https://play.google.com/store/apps/details?id=com.gladimdim.... https://locadeserta.com/sloboda/#/
Currently it is 2D voxel art but in couple month I plan to upgrade it to real 3D view. Just waiting when Flutter gets support for voxel files :)
https://locadeserta.com/sloboda/
(better viewed from mobile devices) It has PWA and Android support: https://play.google.com/store/apps/details?id=com.gladimdim....
And all version are built on Flutter! It is truly amazing UI framework.
All this is done without any restarts of the server/client app. I have even created a smalltalk-to-dart code generator:
https://github.com/gladimdim/smalltalk-to-dart. It serializes Pharo objects into the Dart class definitions with all fields and even with the fromJson methods!
As a result we created a new interactive fiction format:
https://github.com/gladimdim/GladStoriesEngine#human-readabl...
It is already used by the https://locadeserta.com/index_en.html
And it has a Dart implementation: https://pub.dev/packages/gladstoriesengine. It can be used with Flutter apps in web and native!
In a large application you will need a lot of features, which are provided by default in ReasonML: strict types, runtime validation if you encode/decode JSON, fast compilation time, immutable data.
In TypeScript you will have to add:
1. ImmutableJS + its typings.
2. Runtime validators like json-schema + its typings. Then you will have to write types in TypeScript, and also defined a schema in json-schemas. They can become out of sync very soon.
3. Some crazy hacks to tell the difference if variable is of specific type (like in official docs of TS: https://www.typescriptlang.org/docs/handbook/advanced-types...., Paragraph "User-Defined Type Guards"). This checks are done using side effects like a.swim !== undefined. In 6 months this 'if' statement will contain more and more checks.
4. You are lucky if a package you use has official and maintained type definitions. Or you will end up with custom typings.
5. If you develop hybrid app in JS + TS, then TS Compiler cannot create a bundled final d.ts file which you can import in other parts of your project. You will have to write separate d.ts files, which are bundled by tools like dts-bundle. If you have everything in TS, then this issue is not applicable.
6. Large apps take a lot of time to be compiled by TypeScript.
With ReasonML:
1. Immutable data is in the language.
2. Runtime validators are present (bs-json has them by default).
3. Pattern matching saves you from these crazy checks.
4. You are lucky if npm package you want to use has BuckleScript bindings.
5. N/A.
6. ReasonML compilation is very fast.
1: https://stackoverflow.com/questions/46147250/reasonml-vs-typ...
Though I still miss: 1. MacBook's touchpad :-( 2. Emacs-like keybindings everywhere in OS (like MacOS has).
I can say that development performance was 3x than the same developers in JS. Plus you don't have to write unit tests and deal with grunt/gulp/npm packages nonsense.
We got only one runtime exception - our state was saved in localStorage and pushed into Elm.embed when page was opened. If this format changes in Elm/localStorage - Elm fails to start. It would be nice to get some promise rejected when you do Elm.embed() and it fails to initialize. But we can write our own Json.decoders and parse state inside application - in such case we can even write data migrators for user data.
Next stop for us will be to rewrite some views into Elm and integrate them into huge our JS project.