Don't you also need them in a colo?
748 karma · joined June 25, 2010
http://pauldbergeron.com/
Don't you also need them in a colo?
We're an Ad Tech startup - cross device attribution measurement aimed at CTV specifically... and we have very few clients, just enough to pay the server bills and expenses but not enough to actually pay ourselves. Been like this for 3 years now.
It's hard, because the job is fairly demanding and it takes effort to keep this kind of big data apparatus going, but at the same time it's never quite dead and almost just barely always on the cusp of getting big enough to support ourselves with it.
We tried (and failed) to raise last year, so still entirely bootstrapped. With funding down right now another attempt at a raise doesn't seem like it's in the cards.
Looks great, I love more options in the space for CLI based data analysis tools! Fantastic work!
I believe the author is referencing https://www.essentialsql.com/difference-merge-update/ - which you answered in your first point. There's no UPDATE support yet, therefore there's no MERGE support yet.
I have to provide caution here, when you create views and stored procedures, I've always found it a mess to maintain:
1) VCS for stored procedures and views is usually non existent. Good luck understanding how these change over time and who changed them.
2) Deploying application logic alongside these systems is very painful, because unless you've versioned your views/stored procedures, when you make a breaking change you need to stop the entire application, make the change in the DB, and restart the entire application again on the new version. Zero-downtime deploys would require versioned views/stored procedures.
3) It quickly becomes a challenge to answer the question "what happens when I do X?" reliably, where X is insert, delete, or even select a row. Once you have complex enough stored procedures, modifying the data changes things in unexpected or unintended ways. A dev unaware of how the system works might assume that inserting a row simply inserts a row, but instead due to stored procedures hidden from application logic, it might cascade into inserting rows elsewhere, deleting rows, or modifying other rows in other tables. Discovering these issues without knowing that they could exist is often done around midnight during a production outage, because a new feature was released that did something in the DB that was presumed safe, but wasn't. If the code for the business logic were in one place, the application, it would been much easier to see what the change would actually do.
I understand entirely that performance gains from good DB use are astronomical, but in my humble experience, I've found them to be more trouble in the long run than they are worth.
e: spelling
This, when the scope is limited to yourself, it's very different from when it impacts others.
Back when AOL Instant Messenger (AIM) was super popular, I was in university and had read about ARP poisoning. Our school was pretty cheap, so all the dorms had hubs instead of switches. This meant that it would be, theoretically, possible to ARP poison an entire dorm, MITM attack and read all the text being sent on AIM since it was sent in the clear. I had a bit of a cyber security passion lab in my dorm room, so I wrote a PoC and ran it on a LAN air-gapped from the rest of the network. I proved that it should work for myself, having confirmed that similar cleartext messages would get passed to the machine intending to listen in between two other machines.
I told my classmate of my project and he expressed interest, so I gave him a copy. Fortunately, I didn't add any authorship info, mostly because I forgot to. I did caution him that ARP poisoning is a pretty "noisy" attack, and someone who was paying attention would notice it. He foolish ran it on the university network, and confirmed he was able to see AIM messages flying back and forth for all the dorm, as well as all the other traffic. It didn't take long for our school's IT to notice that one dorm was funneling all traffic through one machine. A week later he was banned from having a computer in his dorm room for a school year. Thankfully he never gave me up, admitting it was his stupidity that brought it on himself, but nevertheless it was a lesson learned - if you're going to play in the grey space between ethical and not, do so responsibility and don't share the exploits with others.
If the banks had any say in if I would have gotten loans that year, it would have been no. And I wouldn't have gone on to a lucrative career in tech.
I'm not convinced that letting loan underwriters pick the future labor force allocation is the solution.
I just wish I could get a job in it.
Do you factor in the costs of dev time in a cross cloud environment at all? Nevermind all the AWS specific tooling and code you write, which needs to be thrown away and re-done to accomplish this?
Don't get me wrong, I love AWS when I'm not paying the bill, it makes my job of shipping features quickly so much easier. It's good and it works well. But it's a little crazy to think it's "cheap" and to ignore the costs of vendor lock in.
Not sure how I’d actually host a web app/site on it, there doesn’t appear to be any documentation on pointing a DNS entry to an entry point or even static file hosting.
Also no notes on HA or reliability, but I guess you get what you pay for in these cases.
SQL_QUERY=<<-EOS
SELECT
category.name AS category,
composition.key,
composition.composer,
composition.name AS composition,
concert.name AS concert
FROM
category,
concert,
composition,
program
WHERE
julianday(concert.date) < julianday('now')
AND composition.category = category.name
AND program.key = composition.key
AND program.date = concert.date
ORDER BY
category.sequence,
composition.key
;
EOS
textql --header --dlm=tab --sql $SQL_QUERY category.tsv composition.tsv concert.tsv program.tsvhttps://opensourceconnections.com/blog/2013/05/06/does-found...
It would be really cool to find it, if it's still out there.
Just report the poop on 311 and they go clean it up. Yes it works.
What models work with minimal fuss? What about updates? How do I know that an update won't replace/delete some kext that I need and brick it or break some required functionality?
I really wanted to do this a year ago - except there wasn't any hardware that seemed to answer those questions satisfactorily. In the end, the stability of knowing I can turn on the computer and start work every day without worrying about having to drop into a recovery console because an update f'd is worth more to me than a few grand.
Maybe things have changed?
> We just used global mutable state instead of the whole immutable Reduxy patterns people liked to enforce. It was simple and it worked great.
[1] https://medium.com/@gabriel_20625/technical-lessons-from-bui...
What am I missing?
There's not even a privacy policy on that page, no indication where your servers are hosted or what laws they are subject to.