I'm was still trying to process that the process of our process is to process the process to ensure the process has processed the process when I came across this rather insightful comment about the FizzBuzz Enterprise Edition:
A combination of wasteful architecture astronomy and legitimate need to divvy up absolutely mammoth line-of-business applications among teams with hundreds of members operating for years with wildly varying skill levels, often on different subsystems from different physical locations, with billions of dollars on the line. You can't let the least senior programmer in the Melbourne office bring down the bank if he screws up with something, so instead you make it virtually impossible for him to touch anything than the single DAO which he is assigned to, and you can conclusively prove that changing that only affects the operation of the one report for the admin screen of a tier 3 analyst in the risk management group for trans-Pacific shipping insurance policies sold to US customers.
The tradeoff is, historically, that you're going to have to hire a team of seven developers, three business analysts, and a project manager to do what is, honestly speaking, two decent engineers worth of work if they were working in e.g. Rails. This is a worthwhile tradeoff for many enterprises, as they care about risk much, much, much more than the salary bill.
(I spent several years in the Big Freaking Enterprise Java Web Applications salt mines. These days I generally work in Rails, and vastly prefer it for aesthetic and productivity reasons, but I'm at least intellectually capable of appreciating the advantages that the Java stack is sold as bringing to users. You can certainly ship enterprise apps in Rails, too, but "the enterprise" has a process which works for shipping Java apps and applying the same development methodology to e.g. a Rails app would result in a highly effective gatling gun for shooting oneself in the foot.)
And how having attended several scrum meetings (at the behest of our Corporate Overlords) for “Project: Gibbons” (a slimmed down and simplified version of “Project: Lumbergh”) I can see how this “enterprise development” is shaking out—it's a form of Conway's Law: “[O]rganizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” It's gone from what should be a simple one week project (because all it's doing is looking up a name based upon a phone number and that's it) into a multi-month project mired in internal bureaucratic overhead. I'm not going to go into details, but just note that yes, Dilbert is a documentary.
It's been a long time since I last mentioned The Electric King James Bible, an experiment I did back in late 1999 in URL addressing a portion of a document (which influenced the structure of my blog). The code hasn't changed much since 1999 (there was a bug fix around 2010 it seems), and thus, it has sat there, chugging along with little attention to the greater world.
Until the past month when I've had email discussions with two different people about The Electric King James Bible. Both people were interested in the addressing scheme, which I think is still unique on the Internet. How many sites will let you link directly to a portion of the Bible and get Noah's Ark or Samson and Delilah? It can also handle some pretty bad misspellings (levitakus 19:19 anyone?). One of the respondents mentioned it would be nice if The Electric King James Bible was available via Gopher.
Well, yeah, I do have a gopher site, so it wasn't all that difficult to present a similar interface (in fact, it uses the same data files as the web version). So of course now you can get your Noah's Ark story and Samson and Delilah story from gopherspace. And any other Bible story you care to, just as long as you know where in the Bible it resides.
As long as I was making The Electric King James Bible available via Gopher, I thought I might as well adapt The Quick and Dirty B-Movie Plot Generator to Gopher as well. It pretty much works the same as the web version. Just reload the page for different plots and when you find one you like, you can just bookmark it.
The breakroom of the Ft. Lauderdale Office of the Corporation. On the counter are several boxes clearly labled “Krispy Kreme.” Sean walks in.
Dum de dum.
He stops dead in his tracks as he spots the Krispy Kremes.
- Booming Voice
We don't see the person speaking, but it's a booming, Brian Blessed like, voice. As a side note, perhaps we can get Brian Blessed to play this part. Anyway, booming voice, unseen person.
Make a SAVE vs. Krispy Kreme!
Reaches into his pocked and pulls out a twenty-sided die. He shakes it in his fist and then rolls it on the counter. His eyes goes wide. CUT to die rolling on the counter.
ZOOM to CLOSE-UP of the die on the counter. You can clearly make out the “1” on the top face of the die.
Sean then dives into the Krispy Kreme boxes …
Nom nom nom nom nom …
I would like to write an Apache client to have a specific layout for requests to a secure site, making a static website, not locally, that may look like a assembly loader. This is my first attempt at using SSL. It's a bit simple to do with a few steps, asking the user to decide whether I should use "Google App Engine" or "Google Apps", and then have them send a sort of hash in the request to that domain. However, I still want my site to be public so I can just open it in Google App Engine.
The reason is that my client does not want to do a simple submit / form put into my app, since that 'd be possible with the Google App Engine. The reason I want to use the Google App Engine is that it works as expected. However, neither of the examples I found for handling the request from the parent page (which I am guessing are compatible with the Apache re - server - side tomcat) work as discussed in the link at How to open an IE include in a new application in Python? and all, and the one i've tried. Is there any way I can help my client AJAX to connect to my Python app?
This is not a real question, no one actually asked for this. This question (and every question on the site) is a computer generated word salad that almost, but not quite, makes sense. You know, like a few questions actually asked by real people at Reddit or Stack Overflow who don't quite grasp the whole concept of programming, or English, or both.
And the creator of the page is a bit worried about this site being indexed by Google. It's a valid concern that this site will pollute search results, given that the corpus used to generate the questions are questions on other sites like Reddit and Stack Overflow. There were also some comments about autogenerating answers but given the questions are maddenly close to comprehension, the lack of answers might be a good thing.
But this does give me an idea for National Novel Generation Month 2019 …
I was using my computers when all of a sudden, I couldn't select anything with the mouse. My intial reaction was well, there goes the other PS/2-to-USB converter, but some subsequent experiments proved to me that wasn't the case—I could still move the mouse pointer, and the middle and right mouse buttons worked. It was just the left mouse button that no longer functioned.
I have a Logitech Trackman Marble from the 90s (it's not the same as what is being sold today as the Trackman Marble), and it's the second such unit I've used. The first one wore out and I had to go to Ebay to find a replacement a few years ago, I liked it that much. The thought that I would have to go through that trouble yet again filled me with dread.
In the meantime, I couldn't effectively use my computers. As Bunny and I were scambling to find a replacement mouse at Chez Boca, I decided to crack open the Trackman and see what might be the issue. It was easy enough to open, remove four screws and the innards were exposed. My initial thought was that the left mouse button (which gets the most use) had worn out. It was, but not in the way I expected. There's a portion of the button you press that activates the switch below it. It's a small vertical piece of plastic that pushes down on the horizontally oriented switch. And in that small vertical piece a groove had formed over the years of use.
After discussing the problem with Bunny, the solution we came up with was to use a small amount of Elmer's Glue (applied with a toothpick) to fill in the groove that had formed.
I want to report that the solution worked wonderfully! The Elmer's Glue hardened enough to make the left button work and if it ever wears out, I know how to fix it.
I'm not addicted to the Internet. I can give it up at any time. What? You mean it's down? Aaaaaaaaaah!
Ah, the sweet fast Internet is back at Chez Boca.
Late Thursday, the Internet here at Chez Boca went bonkers (that's a technical term). One second we were smoothly surfing the Intarwebs and then the next, we smacked against the concrete pylons of a pier (if I'm to keep with the surfting metaphore). The connection wasn't down, and it wasn't as if there was massive packet loss. It was just that each packet was taking, on average, about eight seconds to traverse the link.
Things would be fine for a few seconds, maybe enough to start loading a page but then—BAM! 10 seconds! 8 seconds! 11 seconds! 4 seconds! For the next few hours or so. Then then latency would drop to around 30ms for a minute or so, then the multisecond latencies would drive right back up.
And the packet loss was usually less than 2%.
It was weird and annoying.
When we called our ISP, we were first told that someone would be available to check on Tuesday, but when Bunny suggested to tech support to look for any cancellations, they were able to find an opening for today.
It turned out to be a bad DSL port.
In looking back over our nearly 30 hours sans Internet, it's amazing how dependent we've become on it just being there. No email. No Netflix. No quick Google searches when doing a crossword puzzle. No MyFaceGoogleLinkedSpaceBookPlusIn.
Okay, that last one isn't bad at all.
But the rest … wow.