I love Org mode but the fact that relies on emacs can push some people from using it.
I've been using lately [logseq](https://logseq.com/) and it's fantastic. Has the features I love from Org mode, plus what I like from Workflowy, stores the data in plain text in Markdown and supports cross references, images, and more.
I love the idea that there's still an active community developing for old hardware. Specially on videogames since many times they apply modern design ideas in very old hardware.
As a dumb example I saw a platformer for the ZX spectrum not long ago, where the falling speed was not linear but accelerated, which may seem trivial now but back then was something really unusual and I didn't realized how big was the difference after watching it. Then you have stuff way more complex such as the RTS for the Commodore mentioned by the author.
About the quote. Bill Gates said once in an interview:
> I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time.
For the Amstrad CPC too.
There are a number of production and events every year.
The article mentions coding in C++ (which, except for the << operator, is actually C) and with a generic (and therefore a little clumsy) interface to assembly-level DPMI stuff.
64kB is enough to run non trivial programs written in modern C.
(Disclosure: I wrote it:) A cross-development environment with a thin and clean C API to the original assembly-level firmware interface of the Amstrad CPC.
I learned C# a while ago when started a project in the now defunct XNA. I loved how I felt like home when moving from Java bit with some really nice differences.
I thought that after open sourcing .Net the C# adoption outside the MS ecosystem would be wider by now, but I feel it's not the case. Or am I missing a trend I'm not aware of? (which is very likely too)
There is still wide resentment towards Microsoft, just go to /r/programming and check out threads about .Net, there's at least a few threads at the bottom going "EEE".
Plus dotnet core wasn't API stable until recently. I think we're still 1-2 years from mass adoption.
Also check @librexpr's comment above, there's a lot of confusion around.
It's still not really any where near finished is it?
I think they finally managed to get image manipulation in to replace the missing System.Drawing, but EF Core is still woefully half-finished.
The literally seem to have no clue about how people actually use their system and keep focusing on all the wrong things. Actually, it's more like some idealist programmers have become the core team instead of getting-it-done programmers, so it's all the latest fads instead of getting finished. The obsession with async isn't helping either, it makes the code so bad for no real-world performance gains.
My impression is they are moving super slowly and from the POV of an existing customer, the whole process has been a complete disaster. It might end up ok, but at the moment it's just a bad version of existing .Net.
Your paragraph about they "literally don't know how people use their system" seems obvious to me that you must be a 10x mega developer with insider knowledge. Idealist programmers, you're right! Async await offers NO benefits and was implemented in es6 as a mistake... probably corporate bullying.
It's slow going but I'm not sure that's bad or unexpected. MS bought mono and that blessed it as a platform that isn't dead in the water. Most existing projects are fine staying where they are until Microsoft hardens .NET core.
C# is significantly missing tooling. The tooling on Windows is okayish, but that's about it.
You have no cross-platform build and dependency management tool that runs on .NET Core (Using MSBuild and NuGet together requires Mono or the full .NET Framework), and there's only an early version of JetBrains' Rider IDE for non-Windows platforms, there's basically no working integration with any CI or CD system, and the library ecosystem is basically not existing, compared to the open source Java world.
This is just incorrect, and getting more incorrect every day. Rider is RTM, and works beautifully, particularly with .Net Core. It's trivial to setup CI/CD with Jenkins, or TeamCity, or VSTS.
What library support is missing on .Net vs the JVM? In my experience everything that's really useful has .Net ports.
Then please help me — I'm trying to use C# more again — what I should use for dependency management, builds, and artifacts deployment (basically, an equivalent to gradle) on .NET Core. I'm seeing Cake, aka C# Make, but the C# subreddit told me that's useless and I should just use MSBuild. But that doesn't get me my dependencies at all, and doesn't run on .NET Core. I could write a bash script to invoke nuget and the C# compiler but that would be ridiculous.
For libraries, from http2 to time + date libraries, C# is lacking, in tmy last project I ended up straight up translating the parts of JSR-310 I needed.
I'm looking for a 1:1 replacement for JVM languages here, especially regarding tooling. Rider has proven much less mature than IDEA for now.
Trying to directly translate a Java-style workflow to .Net is probably going to be tough sledding; it's just not how things are done. You can do it, but you'll fight everything more than being on the happy path. The dotnet CLI tooling is relatively slick, from what I've seen.
Basically everything. In my web projects, gradle runs css and js minification and compilation, and in game projects, it runs the asset preprocessing.
The build-time code is handled with gradle’s buildSrc folder.
I also obviously use Annotation Preprocessors to pre-generate code for my Java projects, and additional build tools to further minify and optimize the output (e.g., for Android, I also run redex over it).
Basically, gradle for me handles the entire build – fetching dependencies, building native libraries, running code generators, building Java code, binding them together, processing assets, compressing the result, and optimizing it all – and deploying the results.
"dotnet publish" should have you covered for restoring from nuget, compiling and producing a deployable package. Is there something it's missing for your use case?
Noda Time might have what you need in a datetime library.
> "dotnet publish" should have you covered for restoring from nuget, compiling and producing a deployable package. Is there something it's missing for your use case?
Thanks a lot – this is the first time someone actually provided a useful solution, this might actually work well enough for simple projects.
> Noda Time
Also thank you a lot, that actually is significantly better than Joda Time in the Java world, and as result, actually useful (in fact, it feels like a 1:1 clone of JSR-310, at least from what I've seen in their API docs)
I used Waterfox long time ago, as a fast 64bit alternative to Firefox (although never noticed a significant speed difference). Now I think the only reason I'd still use it is because add-ons such as Vimperator, but I already switched to the less powerful Vim-fx.
I love the idea that projects such as this one or Pale Moon exist, but I find it hard for me to use them as a regular user, apart from sentimental reasons.
You are right, and in fact is vim-vixen what I'm using right now, I guess after trying so many alternatives after updating to FF57 I just got confused about what I finally had installed.
I've been trying a few of them out. I had to look at which one I had installed. Unfortunately, there doesn't seem to be any plans to put in the proper APIs to make anything nearly as useful as vimperator.
Delivery rates on AWS are not great in my experience, and there's no easy way to automate some kind of event triggering when a delivery has failed (ended up creating a lambda that reads the fail events from cloud watch). Plus, you have to specify a monthly spending limit that must be manually reviewed and enabled by Amazon, if you go over the limit, Amazon starts failing the SMS delivery, even when SNS responds with a successful status.
AWS is great, but the biggest advantage of Twilio and other SMS providers is that they are way easier and straightforward to integrate.
We are looking for senior iOS developers (full time) for building a unique project focused on building state of the art mobile services that power digital marketplaces worldwide, with data and traffic from 30+ of diverse sites. This is a unique opportunity to help design, build, and scale the mobile and multi-channel aspect a brand new service oriented platform powering great user features for our sites. The services are ranging from ad management and fraud detection to personalized, data-driven search and recommendations, and user to user communication.
Great environment, awesome city and no need to speak Spanish (English is a requirement)
For more info contact me at nicolas.hormazabal@schibsted.es
