For our website builder (https://pinkpigeon.co.uk) we once chose an ORM (GORM for Go specifically).
In case you don't know what this does, it's an abstraction layer for working with databases like MySQL, PostgresQL, etc.
Everyone warns against using them, but in the very early days of my learning Go, there was a tutorial that included this, so I just went with it.
ORMs give you some advantages: Switching database drivers (aka, switching databases) is pretty easy. If it's supported by your ORM, you can then just switch to a different DB entirely.
For the simplest of operations, like just writing stuff to your DB and then retrieving it again, they work a charm. Especially in Go, the ability to automatically marshal things into structs is a blessing.
BUT, then you try to start doing things with many2many relationships, or retrieving sorted data in a very specific, nested query and things go sideways quickly.
I ended up finding it much harder to try to figure out how to do some pretty obvious things. Endless hours on Stackoverflow fighting the ORM and its shockingly bad documentation...
Python - I had side project, an Excel "database" that needed some graphs done in a much faster manner. I had been out of programming full time for about 20 years, and figured that Python with GUI builder would be the way to go.
I had foolishly assumed that the tools had gotten better in the past 20 years. The last major programming I did was in Delphi under Windows XP, etc.
I was dead wrong. I burned through two different GUI Builders each ending up with 20minute to 1 hour cycle times every time I changed a major GUI element. The base problem is that these tools don't allow two-way changes, they only create a python file to then use. I ended up creating a set of files that allowed me to decouple the generated python from my code, and it mostly worked.
It was when I needed to change the type of control from a list to a combobox that everything broke. I had taken far too much of my free time learning and getting this to work. I tried out Lazarus (because Delphi is out of my price range), and it was good enough.
I wasted the code. (In the same sense you waste a via of medicine once you've drawn the dose for the patient)
In less than a week, I was back up and running, and changes were quick and easy to make. Python is good for some things, but a GUI isn't one of them. Charts that took 5 minutes in Excel now take a few seconds in Lazarus.
Gas cooker over induction in an off-the-plan new high modern concrete apartment building. Retrofit for high current turns out to be ruinously expensive.
Imperative-dominant programming language. I think I'd be solving different problems if I had learned to think in functional mode.
If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction?
I have a gas cooker, but have used a induction stove a few times and liked it. The induction model I used was not as controllable as a gas flame, but I understand this can vary by brand or model.
I see induction gaining popularity - it is supposedly more energy-efficient than gas, can cook some dishes more quickly (boiling water is fast), and is much easier to clean than a gas stovetop.
If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction?
We were ignorant of the post-build costs. If we had known the 10x exposure in costs to re-wire, we'd have paid up front for induction.
We wanted Gas because of belief it was "better" for our style of cooking but gas cooking albiet responsive, is highly dependent on the heat energy the stovetop puts out, and the heat energy in the gas supply (pressure) And we kind of missed out on both: a brand name stovetop is disappointingly "slow" even on the wok burner, and our supply pressure is on the low side of normal.
If you have Aluminium or mixed origin cookware Induction usually demands new pans because they must be responsive to induction current. We didn't want to replace a bunch of (to us expensive) cookware. We're now much more aware and buy induction capable replacements, although quite why I don't know: we're not moving, and as this thread says, the retrofit cost for induction is not good.
Induction comes with it's own problems: It's surprisingly noisy, you need to cool those magnetic coils, its bulky under the workbench, and you don't want to put people with pacemakers on your cooktop, no matter now much you might want to experiment.
The cleaning is a huge thing. I do the stovetop, I've used more barkeepers friend in the last year than the proceeding 20 from fat spatter baking on. You can wipe down an induction very quickly after cooking ends.
Ideally? I'd have argued for two gas rings, and a square of induction. Wok gotta wok.
I also noticed the noise aspect with induction hobs. My gas supply provides good pressure for my gas cooker, but despite that I was pleasantly surprised by how quickly foods cook using induction compared to gas.
We switched from gas to induction when redoing our kitchen. We wanted to move the oven and moving the existing gas lines cost as much as switching to induction.
I am in love. So easy to clean, safer, faster than gas. It's annoying having to buy stainless steel pans vs aluminum, but just bring a magnet when you go shopping for them.
Concrete Apartments come with fire safety barriers which are ruinously expensive to breach, if even legal. The rewiring also triggered a review of the in-building current distribution burdens to our apt fuzebox, the costs only ratcheted upward. For a single 3-wire copper run, which could have been put in during first fix before plasterboard, for under $1k.
YMMV. Every home has a different cost and risk burden for this kind of work. Mine just didn't work out for Induction. I was really disappointed.
If we afford a major re-fitout eg to get a walk-in pantry I'll reconsider.
Really? Induction suitable circuit to kitchen should be pre-fitted in the apt design. Same as car-parking charging points: they're becoming mandatory, and I think so should the rollover in cooking power. Building has a 50+ year life, Gas is being deprecated for home use rapidly, its an AGW nightmare even being responsive for cooking and "analogue" right temp when you can get it to work.
Nothing against Angular 2+ ,but I have had a horrid experience with the complexity of the framework. I do admit it was mostly my fault since I went into it blind, but coming from a more jquery/(copy paste and hope it works) mindset, I just didn't really pick up the various nuances of the framework.
But I was lucky enough to work in a different project which had React, and it somehow felt more natural to my brain (more JavaScripty I suppose). I have played around even with Svelte and other frameworks as well, but to me personally Angular always stood out as the worst. By no means my personal view on the framework dimnishes its usefulness and I know a lot of people who prefer Angular. But for me personally it wasn't the best choice.
It's often been the low-code ones. From Multimedia Fusion to Bootstrap Studio. Many come with undocumented bugs or limitations, like loops failing or not being able to do a certain thing. Bootstrap Studio ended up being training wheels to responsive web dev for me.
On the "higher" code stuff, Android is chock full of anti-patterns. Adopting the full repository flow of Android, from web to local database cache will lock you in a lot of patterns. You have to design your data into a way that's easily stored in SQLite, i.e. be pretty damn clear whether your data is an int, string, or pointer, which is hard to tell with new features. And then there's the mess of testing this. Some of these features are still in alpha, e.g. an official library might support pages in the form of integers, but not Strings. So for the most part, you rarely ever want to code Android in the manner that Google teaches you to, unless you're in a company with 10 devs on a team or something.
13 comments
[ 2.9 ms ] story [ 37.5 ms ] threadIn case you don't know what this does, it's an abstraction layer for working with databases like MySQL, PostgresQL, etc.
Everyone warns against using them, but in the very early days of my learning Go, there was a tutorial that included this, so I just went with it.
ORMs give you some advantages: Switching database drivers (aka, switching databases) is pretty easy. If it's supported by your ORM, you can then just switch to a different DB entirely. For the simplest of operations, like just writing stuff to your DB and then retrieving it again, they work a charm. Especially in Go, the ability to automatically marshal things into structs is a blessing.
BUT, then you try to start doing things with many2many relationships, or retrieving sorted data in a very specific, nested query and things go sideways quickly.
I ended up finding it much harder to try to figure out how to do some pretty obvious things. Endless hours on Stackoverflow fighting the ORM and its shockingly bad documentation...
Eventually I just bit the bullet and learned how to write Postgres queries, along with a small Go library called sqlx (https://jmoiron.github.io/sqlx/) which massively outperformed GORM (https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq...) and it's much more straight forward to reason about the relationship between my application layer and the DB.
I had foolishly assumed that the tools had gotten better in the past 20 years. The last major programming I did was in Delphi under Windows XP, etc.
I was dead wrong. I burned through two different GUI Builders each ending up with 20minute to 1 hour cycle times every time I changed a major GUI element. The base problem is that these tools don't allow two-way changes, they only create a python file to then use. I ended up creating a set of files that allowed me to decouple the generated python from my code, and it mostly worked.
It was when I needed to change the type of control from a list to a combobox that everything broke. I had taken far too much of my free time learning and getting this to work. I tried out Lazarus (because Delphi is out of my price range), and it was good enough.
I wasted the code. (In the same sense you waste a via of medicine once you've drawn the dose for the patient)
In less than a week, I was back up and running, and changes were quick and easy to make. Python is good for some things, but a GUI isn't one of them. Charts that took 5 minutes in Excel now take a few seconds in Lazarus.
Imperative-dominant programming language. I think I'd be solving different problems if I had learned to think in functional mode.
If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction?
I have a gas cooker, but have used a induction stove a few times and liked it. The induction model I used was not as controllable as a gas flame, but I understand this can vary by brand or model.
I see induction gaining popularity - it is supposedly more energy-efficient than gas, can cook some dishes more quickly (boiling water is fast), and is much easier to clean than a gas stovetop.
We were ignorant of the post-build costs. If we had known the 10x exposure in costs to re-wire, we'd have paid up front for induction.
We wanted Gas because of belief it was "better" for our style of cooking but gas cooking albiet responsive, is highly dependent on the heat energy the stovetop puts out, and the heat energy in the gas supply (pressure) And we kind of missed out on both: a brand name stovetop is disappointingly "slow" even on the wok burner, and our supply pressure is on the low side of normal.
If you have Aluminium or mixed origin cookware Induction usually demands new pans because they must be responsive to induction current. We didn't want to replace a bunch of (to us expensive) cookware. We're now much more aware and buy induction capable replacements, although quite why I don't know: we're not moving, and as this thread says, the retrofit cost for induction is not good.
Induction comes with it's own problems: It's surprisingly noisy, you need to cool those magnetic coils, its bulky under the workbench, and you don't want to put people with pacemakers on your cooktop, no matter now much you might want to experiment.
The cleaning is a huge thing. I do the stovetop, I've used more barkeepers friend in the last year than the proceeding 20 from fat spatter baking on. You can wipe down an induction very quickly after cooking ends.
Ideally? I'd have argued for two gas rings, and a square of induction. Wok gotta wok.
I am in love. So easy to clean, safer, faster than gas. It's annoying having to buy stainless steel pans vs aluminum, but just bring a magnet when you go shopping for them.
YMMV. Every home has a different cost and risk burden for this kind of work. Mine just didn't work out for Induction. I was really disappointed.
If we afford a major re-fitout eg to get a walk-in pantry I'll reconsider.
Really? Induction suitable circuit to kitchen should be pre-fitted in the apt design. Same as car-parking charging points: they're becoming mandatory, and I think so should the rollover in cooking power. Building has a 50+ year life, Gas is being deprecated for home use rapidly, its an AGW nightmare even being responsive for cooking and "analogue" right temp when you can get it to work.
But I was lucky enough to work in a different project which had React, and it somehow felt more natural to my brain (more JavaScripty I suppose). I have played around even with Svelte and other frameworks as well, but to me personally Angular always stood out as the worst. By no means my personal view on the framework dimnishes its usefulness and I know a lot of people who prefer Angular. But for me personally it wasn't the best choice.
On the "higher" code stuff, Android is chock full of anti-patterns. Adopting the full repository flow of Android, from web to local database cache will lock you in a lot of patterns. You have to design your data into a way that's easily stored in SQLite, i.e. be pretty damn clear whether your data is an int, string, or pointer, which is hard to tell with new features. And then there's the mess of testing this. Some of these features are still in alpha, e.g. an official library might support pages in the form of integers, but not Strings. So for the most part, you rarely ever want to code Android in the manner that Google teaches you to, unless you're in a company with 10 devs on a team or something.
* Silverlight (!)
* Adobe Air (about 2 weeks before it was end dated)
* Rhomobile (native multi-platform mobile build, seemed like a good idea at the time...)
* Microsoft Service Fabric