dimitar

Screenshot here: https://raw.githubusercontent.com/nubank/morse/main/screensh...

That is a read replica, datomic peers can do writes as well, which further expands the possible use cases.

Consider this use case - in addition to your web app, you have a reporting service that makes heavy duty reports; if you run one at a bad time, bad things might happen like users not being able to log in or do any other important work, because the database is busy with the reports.

So in a traditional DB you might have a DBA set up a reporting database so the operational one is not affected. Using Datomic the reporting service gets a datomic peer that has a copy of the DB in database without any extra DBA work and without affecting any web services. This also works nicely with batch jobs or in any situation where you don't want to have different services affect each others performance.

Its true that a lot more memory gets used, but it is relatively cheap - usually the biggest cost when hosting in the cloud being the vCPUs. But usually in Clojure/Datomic web application you don't need to put various cache services like Redis in front of your DB.

Thea assumption here is that the usual bottleneck for most information systems and business applications is reading and querying data.

These companies are not doing any lobbying though, they are helping with the huge amount of paperwork and compliance work that needs to be done.

With Clojure I like using uberjars + systemd .service files instead of setting up Docker

I love there is a rationale, more projects should have one. What problem is the project designed to solve?

It's survivor bias, and a great point to make when people say old construction is better. Really bad construction simply doesn't survive long enough to be considered old

One example is Rich Hickey who wrote Clojure, then his team wrote the Datomic database (on-prem and SaaS) in it.

So why would Clojure or Erlang or Elixir fail to satisfy the need for a functional language capable of taking advantage of the available cores?

It is a datalog dialect, and there a multiple open-source implementations: https://clojupedia.org/#/page/Datalog

Is there a friendly and active chat community for Emacs? There are so many topics where asking for tips and opinions is valuable and doesn't fit well wikis or Q&A formats.

I'm going to suggest Clojure. It is a very opinionated language made a person who was about to quit professional programming because of an explosion of complexity (both accidental and incidental).

Check out the talks by Rich Hickey to see if you have the same sentiment or perhaps this paper: https://download.clojure.org/papers/clojure-hopl-iv-final.pd...

The community of the language largely follows this philosophy, the ecosystem is very stable and there is little churn. The most common implementation is on the JVM making the language very portable.

The headaches historically were with getting your environment setup, but there are amazing tutorials and good tooling or VSCode, IDEA, Emacs and vim.

There isn't a standard, each cloud tries to lock in engineers to it, so they don't compete on price. Any abstraction that is build on top of the different APIs will leak as the implementations are not exactly the same. That is why tools like Terraform just provide a consistent way of working, but then you steel need to learn their APIs as Terraform providers. I think tools like https://jclouds.apache.org/ have attempted some abstraction, but they also have to allow vendor-specific code, so I don't know how much of it ends up being used.

One way you can avoid this problem is by running Kubernetes - then you need to only have code to set it up for each provider and write k8s config that is common to all. Kubernetes is pretty complex though and might not be a good fit for all applications.

The collapse of the USSR wasn't caused by economics or arms races - see how regimes like Cuba, North Korea still survive. Low oil prices helped, but it could have happened during a boom, too. The 80s were not the worst economic or humanitarian crisis the USSR has faced, not even close.

The Soviet Union collapsed because the Party lost control of the country and the tensions and outright conflicts that previously prevented any challenge to its power tore up the country. It was conflicts between the nationalities, competition between bureaucrats of different levels over resources, the young Komsomol chiefs against the old gerontocrats, Moscow against the Russian regions, the Soviet Army against the KGB, the religious against the state atheism, innumerable other conflicts, with probably the ethnic/national conflicts having the most intensity. The USSR found out it couldn't control its own population and that is why it retreated from Eastern European countries as well.

The party lost control because of glasnost and perestroika which unleashed all the contradictions and conflict at once, which further caused chaos. It is no accident that the Communist party got itself banned in both Russia and Ukraine. In comparison China didn't try glasnost and did incremental and initially isolated economic reforms, with agriculture still being restricted to family farms to this day.

The USA didn't win the Cold War or cause the USSRs collapse, most of the time the policy was containment or even reapproachment, not rollback.

It is what got me into writing code. I've tried low-level imperative programming in C which wasn't for me, I never seemed to find object oriented programming intuitive.

What was my frame for reference was piping input and output in bash programming and various declarative DSL like SQL or the Hashicorp language, functional programming in Clojure seemed quite productive and grokable, so I dove into that.

It is not a good idea to have several tools managing the same resources, I don't and for relying on the state file hasn't caused me any issues.

The example you gave is of a wrong way to write Terraform; you should be able to query the cloud API using using data sources. In your case (getting a VNet) that would be this: https://registry.terraform.io/providers/hashicorp/azurerm/la...

In case you need to get the metadata of a resource group you can use this: https://registry.terraform.io/providers/hashicorp/azurerm/la...

I am a very happy Terraform user, here are the benefits for me:

* Very simple workflow that helps prevent unintended consequences - first you write your code, generate a plan, inspect it carefully and only then apply. It is easy to work in a team setting where you can have one person write modules and others supply variables to them.

* I personally don't want to burden myself with Azure Resource Manager, CloudFormation or any other vendor specific IAC tool.

* I don't like other people's bash; there are tools like shell check, but usually a larger infra codebase becomes an awful ad-hoc mess of ENV variables and clever hacks. And infrastructure code is nasty to test and refactor.

Try to keep it simple as possible; anytime you are fighting Terraform it usually means there is a much simpler way to do it. And if there is inherent complexity it could be the wrong thing to do.

In case you need very dynamic behaviour (basically a part of an application) I advise the following - put in terraform the things that are not likely to change often or where the cost of breakage is higher - your virtual networks, DNS configuration, Load Balancers, VPNs, Autoscaling groups, important alerts, etc. Manage more ephemeral workloads in a more general purpose language if there is no straightforward way to do it in the official APIs. I am also very happy user of the AWS CLI in some cases + the cognitect aws libraries for Clojure. However if you need to do something very dynamic it is also likely to be wrong.

I was a technically a loan shark at school, in my early teens.

So I had a fairly small allowance which I mostly saved. Other kids were spending their afternoons at the malls shopping, buying cigarettes and eating fast food.

So the richer kids eventually had their allowances lowered by their parents because of some sort of misbehavior, and it turned out this wasn't very effective as they started asking around to borrow money to keep up their habits.

So I gave small sums of money and since I was a very distrustful teenager I had the following terms - if you don't pay me back by Friday I'm gonna round up the sum or increase it to some other arbitrary point. Usually what happened is they would obnoxiously blow me off, but I would get a concession about increasing the interest further. I didn't want to argue over small sums so I just increased them, giving them a way out of the impasse

In a few weeks the debt would simply balloon and I would start to get angry by the way they were treating me. I learned that I wouldn't get my money by cornering them alone someplace and they would make up credible payment arrangements as soon as possible. I ended up collecting everything with several hundred percent of profit. I learned later that interest rates are calculated yearly and these terms were absolutely insane.

Even though the profits were big the sums were in fact quite small for the trouble, so I just stopped lending out the next year and honestly my market was saturated by then.

My clients probably learned much more than me. At a later time in my life I read 'Poor Economics' and worked with fintechs in an IT capacity. What my teenage self was practicing was fairly common in poor developing countries with next payday or next week loans financing many lively hoods.

I have also never taken a loan, and I'm not planning to.

I assumed employees that are generally high-skilled. So pretty much all of them don't apply if that isn't the case.

Technical Experts-managers are unnecessary where the work is menial, very physical or low-skilled. Or simply best practices or standards are established and followed uniformly. Or regulations are so strict there is little variation on how things are done.

Or the company is driven mostly by brands or advertising.

I spent some time as a middle manager, talked way too much with friends in similar situations at other places and I learned the following:

* It is very easy to be both very busy and do nothing useful at all. Just accept and schedule a bunch of meetings.

* Your potential of improving things depends mostly on the C-level suite. Trying to get buy-in from other levels of management is a waste of time.

* Middle managers are quite often recreating other orgs they aspire to without any thought if their prescriptions are suitable for their orgs.

* The C-level are actually behaving more like individual contributors than managers. The CEO is typically working mostly on closing deals and attracting investors.

* Lower level managers are often created from senior or valuable employees because a title change is the only way of rewarding them and using their experience

* Some of the best managers are HR professionals, but they are completely sidelined. HR is working to protect the companies which for good and evil can clash with your goals.

* No one is a prophet in their own village, not matter how loyal you are climbing the ladder, and how much you learn along the way chances are they are still going to hire someone from the outside to be your boss that knows less than you. It's better to switch orgs when making big jumps in your career.

* There are certain pure management skills (everything with budgets) which are quite valuable, and managers are either undertrained

So, if I ever run my own company of over a 100 people this is what I'm going to do:

- make sure executives / senior managers are doing as much decision making as possible, while accepting input from every senior person in the company, manager or not.

- Promote only experts in their fields, preferably from your own ranks as managers.

- Instead of introducing hierarchy, consider instead providing managers with experts in management as deputies. Recruit fresh MBAs or experienced HR professionals. This way they help instead of hindering.

- Make sure every role has ways to grow while remaining individual contributors. Just give them levels, like Software Engineer lvl 12. Make sure they have free capacity to get delegated tasks or for their own initiatives.

I've worked in place where the majority of projects and the majority of code went in to maintenance. There could be several months or even a year or two of intensive development, with teams reaching a dozen or more developers + QA, DBA, PMs, Ops and a bunch of people on the client side.

And then those projects passed UAT, then went on production, a round of change requests and the teams were disbanded, with maybe a single developer giving some of their time to fix a bug. Sometimes such project went many months or even a few years with no development time spent on them. Some had backlogs of bugs, but it was very hard to mobilize resources to fix them. The company was chasing new project that were bringing more money, so after delivery the old projects had huge opportunity costs, even if there were maintenance fees.

Nothing beats a domain + website, then you can link all kinds of accounts there.

For smaller homes switching from convection to infrared heating helps a lot, heating the surfaces instead of the air, means that letting the air mix by opening a window is less of a problem.

I think the solution is to hire both, because there is also the Peter principle: "promoted to incompetence".

The professional managers should be in a deputy position to the promoted ICs. This way they can bring their skills and expertise in management and empower the promoted ICs who understand the business or problems deeply.

The professional managers can be pretty useful if they don't have people reporting to them and help with processes, compliance, planning, making presentations and excel tables and yet the capacity for damage will be limited as the promoted ICs will need approve anything.

DEC apparently had "administration" instead of management, implying it didn't rule but rather assist, but I don't know the exact details.

Have you tried work that comes to you? Like clearing a queue of tickets in technical support or even accepting calls?

You basically have to show up to work and you are micromanaged by the queuing software. Sounds horrible, but it leads to consistent performance and when your shift is over your mind is clear from work. You are not stressed about procrastination - you just have to respond to stimuli.

You don't have to be very social, the communication is basically a ritual/protocol. If you can clear the first hurdle it might turn out that the formed habits will help you for life.

There are more technical support jobs out there, you just need to make sure they are not organized around projects or a particular big client, but a queue. You are in Eastern Europe so there might be some opportunities around you.

You can give it a try and see how it feels for you.

I looked through the linked claim that Wikipedia is biased and it seems like the bias is not putting a particular political agenda front and center. In the example is the Wikipedia article not talking about highly dubious Fox news "scandals" during the Obama presidency; I checked the Donald Trump article and he gets the same treatment.

I like the bias of not treating politics as a set of "scandals" just like the media does. It is likely that being an international effort, the English Wikipedia avoids voting in a particular partisan bias, even if it doesn't appear to be so for other languages.

The author does mention debuggers. But you don't normally run a debugger on production or a testing environment and with a REPL you can. A debugger situates a program differently than it is normally used, a REPL connects to your code/state/environment in any stage of development.

The post by David Vujic actually mentioned the significant difference - REPL-driven in the way Clojure programmers understand it is not simply interpreting snippets of code in a separate process, but interacting with a running program, including all it's state and modifying it on the fly if needed.

Clojure programs listen on a extra port that you can connect your editor to and modify the program as it running.

Things like tests and notebooks may run the same code, but don't have the exact state and environment as your running program, be it running locally a staging env or even production.

This is not unique to Clojure, a Common Lisp program was famously running on a space probe and REPLed into decades ago, and Smalltalk code is stored in VM images, but few mainstream languages nowadays allow such interaction with a running program

Hmm I can't seem to find any Bulgarian sources citing any religious controversy around the statues, BNT vaguely mentioning that the statues "met the disapproval of some of the locals". I doubt a whole town will ever agree on everything. And given how secular Bulgaria is I doubt it is a big thing.

I will try to check them out next time I'm in Varna

So what other possible solution there is? Cut scope? Hire 200 more people?