nihil75
You're probably right - I'm sure this has more features coming from Logic programming, And I'm just too hung-up on the Concurrent part of the title.
In the article example, it doesn't look like anything is returned from each parallel function call. the main loop just invokes the func for each I, and they print when done. No shared memory, no scheduling or ordering.. what's the advantage here?
In code examples, seems shared memory & scheduling are not a thing either. More like functional or chain programming - a function calls next func and passes output to it. Each loop runs independently, asynchronously from others. Reminds me of ECS model in gamedev.
That's great and all, but it doesn't solve or simplify intricacies of parallel programming so much as it circumnavigates them, right?
Is the advantage it being low-level and small?
I think the same "concept" can be done in Bash: ```for i in $(seq 1 100); do fizzbuzz $i & ; done```
You say Agile disrupts your "flow", makes you deliver buggy code and just work to close tickets like a drone?
Good! Who said code needs to be perfect and bug-free? remember Lean? Just get it out there! we can always fix things later.
From a business perspective - we are spending money to develop functionality, not our peoples skills. Tickets and tasks should result in adding value to the business, not to our codebase.
This is a cruel and unsustainable way of thinking, which will have your best developers leaving the company very quickly. But if you're an enterprise corp - you see them as interchangable "resources" anyway, and Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This is also a way of looking at things...
We keep it small, team level (6 people), and they last 15 minutes.
No pressure to describe anything - you can say "I'm still working on that thing" and that's that..
Honestly it's more of a social thing, especially while remoting, and a chance to share thoughts and offer assistane.
It's a good way to set expectations for what will be/is to be delivered in a Sprint, and limits going off-piste in too many directions while not delivering functionality (which is a problem for creative/broad-skillset developers at times).
It also limits the impact/waste in case the requirements change - you only worked two weeks in the wrong direction. (and they say changing requirements is the biggest problem in software projects since ever)
However, I find that it often reduces developers to mindless drones, just trying to satisfy acceptance criteria without thinking about the big picture. (You know you're there when Refinement meetings are very quiet and the Architect does most of the talking).
As for estimation/scoring - I find that estimating "complexity" is nonsense. Treating points as "days" is more realistic and leads to better time management from everyone.
More accurately, if you need to learn new things to complete it - it will be very time consuming.
Someone experienced, or that uses relevant tech/skills on a daily basis should complete it in less than the time allotted.
Therefore "homework" coding challenges are useful for discerning if a candidate has relevant, current experience.
See the article on college professor solving a 30+ of CS problems in one day.
Whiteboard challenges, on the other hand, evaluate a candidates thinking process & presentation skills.
Whiteboard challenges
- Coin-sized brain implant, flush with skull, no external wires.
- 1024 channels EEG
- Electrode insertion with minimal brain-matter loss
- Analysis and prediction of brain-activity (node-beep and motion joint positions)
If so, reports are that the battery life is extremely short.
Early days, I get it. If I find a way to run it on Linux will post here.
Taking it for a spin.
It could be that there's just a higher ratio of these types of images.
Reports are coming from Serbia, Australia, South Africa and I can confirm Netherlands as well.
Don't over react, don't spread misinformation.
I think basing tenure decisions on the fact papers were published there is based on archaic notions and misguided.
He's probably preparing the thumbdrive the old-fashion way, jusr dd'ing the iso into it. You need a modern prep tool that's UEFI-compatible for it to boot on new hardware.
I also really like CouchDB which IBM Cloudant is based on.
Is that enough for me to use IBM cloud? no. not really.