Disqus - Latest Comments for drawohara

Re: I Have Embraced Absurdism

drawohara — Tue, 17 Jun 2025 16:07:23 -0000

fair. and perhaps he is indeed an absurdist. i suppose it's more accurate to say that it is the _response to the absurdity one chooses that can be dangerous.... as camus pointed one there are 3 choices next: 1) suicide. i've known many of these. not a great choice IMHO. do not recommend. 2) faith. in something larger than one's self. combined with a philosophy of service. this is the choice Rovelli, and Kastrup, espouse voraciously in their writings. 3) rebellion. freedom. nihilism. trump is this type of absurdist. so is musk. so is thiel. we see many of these kinds acting in the world and, we can pretend it doesn't cascade volumes of '1' mentioned previously onto the young and old, if we ignore the data, and we can pretend that choosing '2' doesn't manifest in *wildly* different ways of moving through the world than '3'. so, my observation stands: it is a wildly dangerous viewpoint that can have an unfortunate response. i am assuming you have read camus as well so, since we all agree that it is definitely absurd, which response is it that are you are choosing? perhaps i've mis-read your recent writing but, from over here, it very much sounds like number 3 ;-/

Re: I Have Embraced Absurdism

drawohara — Mon, 16 Jun 2025 17:58:58 -0000

this is a dangerous viewpoint. for you most of all. you (or anyone), will need to _work at this one but ->
https://www.youtube.com/watch?v=9yOs3zfCjvQ
if science said that time and matter were not fundamental aspects of reality.

if reality was mental, and what you thought mattered, that would change things, wouldn't it? ->
https://www.youtube.com/watch?v=-6rWqJhDv7M&t=17s&pp=ygUNY2FybG8gcm92ZWxsaQ%3D%3D

Re: Three Thoughts on AI and Life

drawohara — Sun, 15 Jun 2025 01:47:14 -0000

this is nihilism. pure and simple. the kind that makes people convinced that nothing but profit matters and that we have no responsibility in the world. it's the kind that recycles every aluminium can... from inside a 30,000 square foot house. some of us see through it. it's very, very, very sad.

Re: Japan Cup 2017: Results | Cyclingnews.com

drawohara — Tue, 24 Oct 2017 01:05:01 -0000

at what point does cyclingnews stop looking like a douchebag that can't see a doper from 100 miles away?

Re: Give science a chance in Boulder County crop crackdown

drawohara — Tue, 25 Apr 2017 13:29:09 -0000

definitely irrational commissioners - but given that is a requirement to be good in politics it is no surprise. what irritates me is the totally crap line of reasoning the journalist used, along with dubious support...

- what problem is science solving here? not enough food in boulder? not enough money for crops? feeding the poor? he opens up claiming the commission is mis-guided without even hint as to what the guiding goal is, theirs, or his. his own goal seems to be 'use a hammer because i like hammers'.

- comparing the body of evidence behind climate science and ag science. there isn't even *close* to the total numbers. not to mention one group of studies has downward pressure from econmics (gas companies want fossil fuels to stay) while ag science is funded by, and has the complete opposite economic pressures, largely being funded by the same companies making the seeds, plants, machines. etc. oh. and no numbers. just 'more bigly more studies'

- just stop and say we need more corn. it is piled up in wharehouses across the nation. again, what problem is being solved? selling more of a crazy subsidized crop? surely no is going to suggest that gmo crop suddently will convince our policitians to donate surplus food?

- "give science a chance" - is he kidding? these guys are driving 500,000 combines with radar, stereos, gps, and programmable tracks around already. suggesting that this choice is somehow anti-science is just inane. it may be anti gmo, but not anti-science. total, bogus, straw-man / 6th grade baiting.

this really feels like the kind of argument that comes out of a high school debate class. maybe vincent can get a job at the high school paper?

Re: Why WeWork.com uses a static generator and why you should too

drawohara — Fri, 11 Dec 2015 11:00:38 -0000

"depends on everything" being the first hint at why dep tracking is not a good approach for websites generally. with included (db backed / included) content it is trivial that /a depends on the content from /b, and /b depends on content from /a - it absolutely can be done, just not with make

Re: Why WeWork.com uses a static generator and why you should too

drawohara — Fri, 11 Dec 2015 10:03:25 -0000

yes, i've done it. the rule is "/posts/index depends on the most recently created featured articles" - it ends being very difficult to maintain and people generally punt and say "you can only feature 3 articles", but then that spirals out of control when you want to feature "#computer-science" articles on /comp-sci and "#security" tagged articles on /security. the reality is that websites are graphs with cycles - not DAGs - and this makes 'make' a terrible tool for doing cache invalidation.

Re: Why WeWork.com uses a static generator and why you should too

drawohara — Thu, 10 Dec 2015 10:31:04 -0000

because dependencies are hard: if you have /posts/index.html with a 'featured content' section, where featured is dynamic, that is a hard thing to express via deps.

Re: 5 Early Lessons from Rapid, High Availability Scaling with Rails

drawohara — Mon, 29 Dec 2014 12:49:56 -0000

tone doesn't work well via text at times mike, but i assure you i'm over here expressing nothing but surprise and curiosity - sorry if it didn't come across that way on the tubes.

i'll also extend an invite to coffee/lunch (on me) - we're at pearl/17th in boulder - http://dojo4.com/contact.

i'm really interested in how you made the first analysis, and how you're making the current/next one, which is definitely thread hi-jacking ^ this article so i'll leave it that.

cheers.

Re: 5 Early Lessons from Rapid, High Availability Scaling with Rails

drawohara — Sat, 27 Dec 2014 15:03:11 -0000

mike -

great response.

first off, no one is on ideal stack and lives with it - totally get that.

second, no one is bashing pg. it is great, and will always have a strong place in the market and looks to be the best rdbms choice for a long time.

third, sharing your learning is also fantastic of course!

forth, some answers to your questions...

> It would be helpful for you to elucidate under what scenarios these tools would be better, and why. I do not believe they are simply better general purpose technologies.

the scenario i see non-rdbms as better are situations where:

- a sophisitcated caching layer (non-simple http cache) needs to be added. caching of core data structures outside the main data store obviously adds an eventual consistency property to the system, removing the C from ACID and indroducing CAP.

- when lots of background processing needs added to throttle writes. again, adding eventual consistency via CAP.

- when data structures, not blobs, need to be cached and queried. you've added redis for this purpose, but it's a big hint that a more object-ish db is required. could be redis, could be neo4j, could be mongo, etc.

- when the data model's indexes cannot be know apriori and might require indexes being built in the background while reading and writing continue (rdms.nope, mongo.yep)

- when your data volume is going to grow in a way that is going to require you to shard. sharding generally prevents joins and the kinds of complex queries an rdbms allows. it also totally removes ACID and introduces CAP to the system by itself.

- when your data access requires trying to keep data in memory: a huge hint that a db optimised not for durability, but for speed, is required.

- when you realize, during migrations that your data can be easily lost and contains lots of duplicates, proving that a db system itself cannot actually provide durability or consistency to a system as a property.

> Can you give me an example of a scalability issue you anticipate we will run into?

- redis objects provides neither atomic operations nor good querying as you suggest: the atomic properties are lost if you need to act on two keys, and the intersections, and other fancy queries poop the bed once you have to shard.

- any future missed index or data quality issue is going to require exponentially more work to repair due to pg's inability to create background indexes and massive table-level alterations without taking the system down. this is especically true with sharding.

- one of your data layers has entirely different scalability characteristics than the other and so there will be an increasing impedance mismatch which will, i predict, force you put more and more data into redis while still requiring you to scale pg at the same time.

- once both redis and pg are sharded you'll handle cap in an ad-hoc fashion across the application, sometimes chosing read-consistency, sometimes chosing write-consistency, each time implemented in a way that's impossible to test and reason over at scale. this will introduce hard to find bug and increasing data inconstency, leading to lots and lots of code that handles read-time errors gracefully. (hello again CAP).

- getting a parallel test system running that has all the properties of production is going to become increasingly difficult due to the different streaming capabiliities of redis and postgresql. this, with the fact that pg has hard schemas is going to make integration testing impossible (as i'm sure it is now).

the main point i'm trying to make is that you identified needing things like:

- a fast, queryable cache of objects
- the ability to manage shards independently of application logic
- the ability to do lazy replication and data migrations
- the requirement to do complex atomic operations on data strucutres

and eventually added these things via redis and pg sharding. but, now, you are using pg in a way that has NONE of the ACID properties people chose it for and have a system that has all the complexities of CAP, but in a totally new a proprietary way. so, instead of being able to consider the data layer and it's consistency as an abstraction ello engineers are required to grok consistency spread across two layers (redis and pg) in a way that will continue to change as you scale: maybe you can do a join this week, but not the next, maybe you get an exception if you violate that unique contraint, maybe not, etc... people will need to understand the physical stoage layer, replication strategies, caching stratigies, and application code to correctly read, write, or query data.

it's challeging to imagine this won't become a liability to development as compared to abstracting all of that behind a well documented data store that provides the requirements of the system out of the box as an abstraction layer that needs comparatively few levels of reasoning in application code. there is a reason facebook wrote casandra and there are reasons mongodb addresses each and every roadblock you hit without exception.

again, i'm really not trying to troll, but i'm simply surprised that ello struck out to build a better social network by ignoring all the engineering lessons those that came before them have learned about the properties of web scale graph based near-realtime systems.

Re: 5 Early Lessons from Rapid, High Availability Scaling with Rails

drawohara — Fri, 26 Dec 2014 12:39:49 -0000

i'm a little surprised by much of this article. as someone that's been building web applications on postgresql for 20 years (srsly - http://www.postgresql.org/m... there is zero chance i would have reached for postgresql to build a social networking app - the reasons are all the ones you've listed. the result of doing anything webscale with pg is adding caching and sharding logic that produces a system that is more difficult to reason about than mongo, casandra, etc. if fact, you've simply re-built a custom nosql store like so many before you. there is a mountain of learning behind modern, horizontally scalable, db systems borne out of decades of people learning these same lessons which is is silly to have ignored. after this experience it seems like you personally learned a lot (like how to use unique indexes), but probably have no idea what scalability issues are lurking around the corner for ello and are following reactionary vs proactive engineering practices since, in ello's case, scaling isn't YAGNI, but a hard requirement with a velocity that cannot be predicted. sorry to sound harsh, but this article reads solidly as a story about how ello wasn't designed correctly and will hit a glass ceiling in the future that will require a massive re-write to move forward ;-/

Re: http://blog.yetanotherjosh.com/post/33685107221

drawohara — Thu, 25 Dec 2014 01:34:01 -0000

@Ari Palo if uploads are not serialized to disk in chunks you happily let any client, anywhere, on the internet, run your box out of memory by simply passing in multipart form upload with a big file. not smart.

Re: An Atomic Rant18 Feb 2010

drawohara — Wed, 24 Dec 2014 23:08:46 -0000

welcome to 'select for update' (RDBMS) and 'find and modify' (mongo) - dumping this into redis just compounds the problem by moving the concept out the primary store (which already supports atomic modify-and-read operations) and into another store, with it's own unique consistency model and scalability issues. nothing is unique about redis with respect to 'evaluating and altering a value' otherwise known as 'read consistency'. indeed, traditional rdbms' even let you do this __across__ values (aka they actually solve your 'edge case' aka http://www.postgresql.org/d.... they've done this for decades.

in addition, because redis is an in-memory store it has uniquely crappy atomic properties in a cluster, as opposed to using either an rdbms, or mongo: both of which can offer atomic operations even in sharded/partitioned setups.

tl;dr; redis is possibly the worst possible solution to consider if one is trying to implement atomic operations in an app.

Re: When Force is Hardest to Justify, Victims of Police Violence Are Most Likely to be Black

drawohara — Mon, 08 Dec 2014 14:39:58 -0000

Lisa, your conclusion that:

"This is about race. It is very, very obviously about race. It’s not a matter of opinion; it’s a scientific question that has been asked and answered."

is myopic and also incorrect because 1) this is a statistical, not scientific, analysis of correlation _only_ (no causation is implied by the numbers) and 2) there is no answer presented in the stats, just data. if we're going to stick to facts then we really also do need to look at the data that shows 1) crime is clearly most strongly associated with poverty 2) blacks are more likely to be in poverty in the US 3) cops are most likely to be white. therefore it is actually possible to explain the above chart even in the complete absence of racism.

i'm not, for one moment, implying that racism isn't an issue in the US, or that it's not a major factor in those homicides, but i am saying that this data does not prove that: it only suggests that we should be looking at other data to discover the causes, which are likely complex and of which racism is just one component, perhaps minor, perhaps major.

we owe this kind of fact driven thinking to the police officers who are not racist and to the people who are seeking to use real facts to create real solutions instead of framing the problem as being simple, thereby undermining the creation of possible solutions which are unlikely to be so simple to implement.

Re: SaaS Product Validation Techniques

drawohara — Tue, 02 Sep 2014 17:57:02 -0000

@ryan it's an interesting one we're having ourselves at dojo4 right now. asking ourselves many of these same questions!

Re: SaaS Product Validation Techniques

drawohara — Tue, 02 Sep 2014 12:28:31 -0000

here's what i find so difficult to believe about this: historically most successful software concepts need to be used to be believed. for instance, if you tried to validate 'dropbox' via some silly survey like 'would you like to have all your files available everywhere' you'd get a bunch of meaningless data. meaningless because it really doesn't help engineerings _make_ dropbox - they'd have zero data other than 'users want it' to guide development. the depth of data you can get through the process above, imho, boils down waving something shiny around and seeing if people think it's shiny. hint: the do.

let me give you a challenge: how can you assert (validate) that pre-validation of sass concepts results in better, more profitable, products than alternative approaches? how can one assert that particular approaches (say approach 1 vs approach 2 above) yields more scientifically valid data than others?

i honestly feel like this the worst kind of pseudo-science: where people use stats to confirm what they already know, or want to believe. a true 'scientific experiment' can only prove that, statistically, a hypothesis is unlikely to be caused by chance alone, and that the target of the hypothesis has a statistically significant chance at being causal to the observed. what you describe above has virtually no characteristics of an actual 'scientific experiment' and might only be called 'looking at data and trying to extrapolate/guess meaning from it'

Re: SaaS Product Validation Techniques

drawohara — Tue, 02 Sep 2014 10:51:32 -0000

you forgot the one most successful sass founders employ: turn off the fucking internet, don't let people tell you that your idea is bad, and actually write novel software.

i'm so fatigued by the notion that creativity is a science and that doing the hard work can be avoided...

Re: How to build a news app that never goes down and costs you practically nothing

drawohara — Sat, 24 May 2014 15:47:54 -0000

we follow a similar strategy and absolutely LOVE it - http://dojo4.com/blog/stati...

Re: one: jud@gnip.com is no more

drawohara — Thu, 01 May 2014 22:37:47 -0000

You've been an example on so many fronts Jud - I know you'll enjoy whatever comes next!

Re: one: Day In Pictures: Another Tuesday!?!

drawohara — Wed, 05 Feb 2014 01:04:05 -0000

good to see you 3 sitting together ;-)

Re: Toward Idempotency | Out of my mind...

drawohara — Thu, 09 Jan 2014 00:41:07 -0000

pushing the ctime and mtime to the time of the commit fixes this globally - for all devs for all boxen. it assumes git.... but this could be detected via .git.

Re: mostlovelyart

drawohara — Wed, 16 Oct 2013 01:38:59 -0000

1) how to do you catch a unique rabbit? -> unique up on him

2) how to do you catch a tame one? -> tame way ! ;-)

Re: mostlovelyart

drawohara — Sun, 13 Oct 2013 02:26:45 -0000

we had to neek up on him (do tell if you haven't heard this one...)

Re: Rally Gives $1.3 Million To The Boulder Community

drawohara — Tue, 08 Oct 2013 22:17:16 -0000

pretty much this is giving back to the community. nothing more to say except *pure fucking awesome* and *let's see more of this* in all our communities.

boulder is made by acts like like this.

Re: one: Should I Do This?

drawohara — Wed, 18 Sep 2013 01:00:47 -0000

shit that's high level - you should map those concepts onto wetware...