To me, it felt like some of the best sleep of my life! The gibberish out of my mouth afterwards thou...well it was a good laugh for my spouse, which is a happy sight seen upon opening my eyes.
Is this actually a business that can make money? My family owns around 1000 olive oil trees in Greece that produce eatable olives and extra virgin olive oil.
The thing is that we always sell the product in intermediates that would pack it up and sell it in a much higher price. I don't know of any small producer that sells the product directly to the consumer. This seems like a very big investment and not really sustainable. Are there other people that are doing it?
Could my knowledge as a software engineer help that family business in any way to be more profitable ?
I sell onions on the Internet [0] is a well known example I've seen, whose author sells Vidalia onions direct to consumers. Another one I know are Miami Fruit [1]. There are no doubt countless examples, but more than software engineering, you need good marketing. If you made an ecommerce site via Shopify (do not code this yourself, it's a waste of time) or wrote a similar article, and posted about them, I'm sure people would find you and order. Personally I'd be interested in buying directly from your farm, let me know how that is possible even if it's a low tech solution for now.
Something you might be able to code is plugins for these ecommerce sites, if it makes sense for your business. I also used to run a loose leaf tea ecommerce store via Shopify but I imported from producers like your family as you describe, and I wrote one for dynamic pricing for buying from various countries due to their purchasing power being less. It'd calculate their power as well as my thresholds and figure out optimal prices where more people could buy it but wasn't screwing me over too.
Most likely not, this is more of a way to retire with money earned from software development and spend time "on business" that isn't really financially viable.
Kudos to author for going this path, but it takes a lot of resources to be able to make a move like this, which is not really an option for a large majority of population.
I always get my olive oil from a farm in Italy that only sells direct to customer. Or my coffee from a shop that gets the beans directly from the farmer (direct trade > fair trade).
It's possible, the market is kind of small I guess but you need to have a product where the customer is happy to pay a premium.
And being a software developer helps because you might have the money to invest?! :)
At that point it becomes an exercise in marketing more than anything else, because the whole business model depends on finding rich customers that are willing to pay a suitable markup to make the extra effort feasabile. And then you have to also be constantly trying to retain those customers....etc
This is insteresting to me especially since this is a 2005 document. Is there a reason why C++ was chosen instead of Ada which to my knowledge was the gold standard for such software ?
A large segment in this article (which is great overall) focuses on this decision. The short summary is "hiring Ada developers was hard and middleware and tooling were difficult to acquire."
While I've moved through a lot of parts of the software industry and may just be out of touch, I actually feel that this may be less the case today. I've seen a lot of school programs focus less on specific languages and frameworks and more on fundamental concepts, and with more "esoteric" languages becoming popular in the mainstream, I actually think hiring Ada developers would be a lot easier today (plus, big industry players like NVIDIA are back to using Ada since AdaCore have been so effective at pushing SPARK, which probably helps too).
My recollection is that it came down to two factors. Pragmatically, the pool of highly skilled C++ programmers was vastly larger and the ecosystem was much more vibrant, so development scaled more easily and had a lower maintenance risk. By 2005 they had empirical evidence that it was possible, albeit more difficult, to build high-reliability software in C++ as the language and tooling matured.
These days they are even more comfortable using C++ than they were back then due to improvements in process, tooling, and language.
For tco to be really useful you need to think in a non procedural way. Imagine that you don't have loops in your language so you need recursion to do stuff multiple times.
Also even in procedural languages there are some problems that are easier to understand and model if you use recursion, for example tree or graph like structures.
traversing graph or a tree is not a TCO case because it would involve a stack/queue for DFS/BFS, whatever.
I dont want to think in non procedural way, I reserve this nonsense to haskellers, please provide me a valid python use case for TCO :)
Traversing a graph and inspecting each node can definitely make good use of tail call optimization.
For instance: you have a large graph and you are traversing a particular path through it — say a R/B tree seeking a node. You can write it iteratively or recursively. Neither needs to hold more than 1 node reference at a time, the choice is which you prefer to read and write.
I prefer to write that recursively. Sounds like you may not. Observing “well I can write it iteratively so why do I need TCO” is obvious and uninteresting; that’s the point.
Using Django for almost 15 years, almost exclusively, for both business and personal projects. Have tried a lot of other frameworks, nothing clicks so good with me.
My only (small) complain with this release would be that they included the task framework but didn't include a task backend and worker. I'd prefer to wait a bit and include everything in the next version.
Minio is more or less feature complete for most use cases. Actually the last big update of minio removed features (the UI). I am using minio for 5 years and haven't messed with it or used any new thingie for the last 5 years (i.e since I installed it); I only update to new versions.
So if the minio maintainers (or anybody that forks the project and wants to work it) can fix any security issues that may occur I don't see any problems with using it.
Well I didn't mind when they removed it and certainly I didn't consider their paid version which is way too expensive for most use cases.
The UI was useful when first configuring the buckets and permissions; if you've got it working (and don't need to change anything) you're good to go. Also, everything can be configured without the UI (not so easily of course).
> So if the minio maintainers (or anybody that forks the project and wants to work it) can fix any security issues that may occur I don't see any problems with using it.
The concerning language for me is this part that was added:
> Critical security fixes may be evaluated on a case-by-case basis
It seems to imply that any fixes _may_ be merged in, but there's no guarantees.
Yes this is concerning for me too. Hopefully if they don't fix/merge security issues somebody will fork and maintain it. It shouldn't be too much work. I'd even do it myself if I was experienced in golang.
reply