dominikh changed the topic of #cinch to: The IRC Framework | Latest version: Cinch 2.0.10
v0n has quit [Ping timeout: 272 seconds]
kludge` has quit [Ping timeout: 260 seconds]
kludge` has joined #cinch
Spami has quit [Quit: This computer has gone to sleep]
Spami has joined #cinch
xeviox|afk is now known as xeviox
Spami has quit [Quit: This computer has gone to sleep]
Azure has quit [Quit: My MBP went to sleep.]
kludge` has quit [Ping timeout: 240 seconds]
CM-Punk has quit [Ping timeout: 240 seconds]
CM-Punk has joined #cinch
jmaister has joined #cinch
<jmaister>
Hi
<jmaister>
What's the best method of adding database functionality to my bot?
<jmaister>
I'm thinking of adding an abstraction layer over SQLite to give the plugins db access
<jmaister>
Do you know of any current implementations like this?
<dominikh>
there's nothing cinch-specific about using a database, really. some use ActiveRecord (because they're silly), some use DataMapper, some use the raw sqlite driver and write SQL queries
<dominikh>
only important thing is that it supports multi-threaded db access
CM-Punk has quit [Remote host closed the connection]
CM-Punk has joined #cinch
<jmaister>
I see
<jmaister>
I just thought adding some abstraction would keep the nice simplicity of the plugins
<dominikh>
well, any ORM is that abstraction
<jmaister>
I'm going to add something. They y'all can have a look at it and tell me I over engineerd it
<dominikh>
sure
<jmaister>
Which I will
<jmaister>
That's how I roll
kludge` has joined #cinch
kludge` has quit [Ping timeout: 245 seconds]
kludge` has joined #cinch
postmodern has quit [Quit: Leaving]
mpapis has quit [Excess Flood]
mpapis has joined #cinch
kludge` has quit [Ping timeout: 245 seconds]
kludge` has joined #cinch
kludge` has quit [Ping timeout: 240 seconds]
kludge` has joined #cinch
<cout>
overengineered means different things to different people
<cout>
to some it means "this thing works great, but you put way more effort in it than was worthwhile, and we could have saved programmer time or cpu cycles by not doing so much"
<cout>
that kind of overengineering is the good kind
<cout>
the other kind is "this thing has so much scaffolding and structure that it's impossible to change and it doesn't actually solve any of the problems you were trying to solve"
<cout>
that's the bad kind of overengineering (the kind you see in the java world)
<dominikh>
the first really isn't overengineered per se, unless you could have achieved the same sort of simplicity with way less code/magic
<dominikh>
i.e. I can write 20 lines of magic that handle every possible case automatically, or write 5 lines that work for 99% of the cases and tell you that the 1% are stupid, anyway
<cout>
in the first case I was trying to describe the Ford car kind of overengineering in software terms
<cout>
i.e. Ford looks at parts and says "this part lasts 150K miles but it only needs to last 80K miles"
<dominikh>
Ford over Toyota's firmware any day ;)
UberDragon has joined #cinch
<cout>
they seem about the same to me
<dominikh>
Toyota are the ones with the buggy firmware that killed several people.
<dominikh>
haven't heard anything of that sort about Ford
<cout>
I was not aware that it had been proven to be caused by bad firmware
<cout>
but I was thinking more in terms of fuel maps and timing maps and such
<cout>
they all work on the same basic principle
<dominikh>
they've published some detailed reports and analysis of the firmware, that it violated a plethora of security standards and was littered with bad programming
<dominikh>
race conditions, hundreds of globals, faulty watchdog, etc
<dominikh>
certainly not overengineered ;)
<cout>
globals in an ECU are par for the course
<cout>
it's a different beast than writing ruby code
<cout>
mainly because these code bases evolved from back when 256 bytes was a lot of memory
<dominikh>
I'd argue they're not the default if they're used for every sort of state. not everything needs to be shared, and more importantly, they should be properly guarded ;)
<dominikh>
"Barr’s group found 80,000 rule violations", "The Camry ETCS code was found to have 11,000 global variables. Barr described the code as “spaghetti.” Using the Cyclomatic Complexity metric, 67 functions were rated untestable (meaning they scored more than 50). The throttle angle function scored more than 100 (unmaintainable)." ;)
<dominikh>
is 11,000 par?
<dominikh>
if so I'll get a bike soon
<dominikh>
speaking of 256 bytes, the report mentions stack overflow
<cout>
I don't know what is par
<cout>
but e.g. on my minivan every single variable is global
<cout>
embedded systems are just historically a different beast
<dominikh>
how do you know about that number?
<cout>
which number?
<dominikh>
eh, not the number, the fact
<dominikh>
on your minivan
<cout>
oh, I've dug into the code
<dominikh>
either way, not everything necessiates globals. I wouldn't be surprised if their code had no local variables anymore ;)
<waxjar>
im gonna hack your tires, son
<dominikh>
more space for their recursive functions (which are forbidden) I guess
<dominikh>
anyway, back to overengineering I guess
<cout>
I'm saying that the current code evolved from code where globals were the norm, so a large number of globals doesn't surprise me at all
<dominikh>
your first example might be more a case of YAGNI