It was 2001 and the thing was on life support while PCs were being rolled out. I was helping to rack my new database servers, which was next to this big lab table/shelf combo with like 16 terminals on it. When pulling a cable I banged my head on the table, then this big book fell on my hand.
About 10 minutes later, a bunch of graybeards come around the corner yelling “WTF are you doing!”
Turns out that the dictionary that hit my hand was perched across two keyboards, holding down the “enter” keys of two terminals. Turns out that for reasons unknown, those terminals had to be repeatedly hitting the enter key in order for the logins and print jobs of about 40,000 people to work.
Back in my CounterStrike gaming days I would also remove the Windows key because it would crash the game when accidentally pressed.
On Linux, it's my meta/compose/whatever key, so I can write äöü on UsIntl via caps-aou ( https://github.com/winks/dotfiles/blob/master/.us-intl-germa... )
Some of my most used shortcuts:
Caps + C = Chrome
Caps + S = Spotify
Caps + A = Atom
Caps + T = Terminal
+1 for removing windows key if gaming
Though, that actually is interesting, and you made me read up ab bit on Japanese.
I ended up coding a utility (in VS6!) to disable the windows key when you launched the game.
http://www.businessinsider.com/the-one-key-that-infuriates-b...
Turns out the cleaners were thorough enough to clean deep down behind a desk and turned off a surge protector that a 5-port network switch was plugged into.
Yup, I IRQ-DOSS’ed myself.
Everything was going digital. We had a “remote” office across the street that didn’t have internet access and it was really expensive to have lines installed.
I don’t remember what the device was called but it was some sort of satellite dish. Our network admin had ordered them and installed them on the roof tops of both buildings and we could provide access via this link.
It was pretty rad to me. But then the intermittent bugs started creeping in. The remote site used some windows 2000 dumb terminals and throughout the day all of them would disconnect at the same time - every day.
It was very random and they’d automatically reconnect after a few seconds to a few minutes - always.
Well, I was the new guy / intern grad. And so after a few weeks of debugging different things inside and moving the dishes around to make sure they were exactly pointed at each other my boss rolls into work with a beach chair and an umbrella.
I looked at him and asked if he was taking off early and hitting the beach and he goes “no you’re debugging”.
We set up the chair and umbrella on the roof. I sat up there with an walkie talkie and the remote site had the other one. My job was to sit until they radioed to see if anything was obvious interrupting the connection.
Then a semi truck stopped at the red light.
We ended up putting the dishes on longer poles. :)
That blew off during a hurricane the same year :)
For some reason, every so often (sporadically) I'd get a segfault inside the closed-source binary blob. To get things "working", in my wrapper, I captured the stack before calling the occasionally segfaulting function, and setup a segfault handler that would simply restore the stack to its state prior to the crash.
Unfortunately, after restoring the stack, a subsequent call to the closed-source function would hang. I did some preliminary reverse engineering of the binary blobs and found that it was segfaulting whilst having retained a mutex. So I did, ah... the obvious thing(?) and just grabbed the raw memory address of the mutex, and released it myself when a segfault was encountered.
Surprisingly this all "worked". In the end I had a TV that thought it was a 65" phone, lock screen and all. Umm, yay!
Here's the code:
https://gist.github.com/Benjamin-Dobell/bb13f6169aaa48625453...
The way you casually explained this to me really threw me off. I remember trying to do some AOSP hacking on some older phones and always gave up. For different reasons
Locked Bootloaders
Huge sources to download
Confusing device configuration (all those xml files were and still are magic to me)
The farthest I ever got was to compile a kernel and flash it unto a phone. I was so happy for so little. The only difference was the change to the build version / name.
I remember back in the pre Ice cream era graphics drivers were the most often quoted reason for older devices getting "stuck" on older versions of Android. It never occurred to me that you can write a graphics wrapper.
The app required a ton of scheduled database and ERP tasks (it used a legacy flat-file db), so the vendor wrapped them all up in a secondary executable that was effectively a non-headless (headful?) daemon (this was expensive, niche industry software btw). The first instance of the application that opened would also trigger the daemon to open too, on whichever PC it was executed on (it was supposed to be opened on the server 1st). It was provided by the vendor this way, as part of the COTS application.
As a result of this daemon hack, every couple days (after the application crashed on the server, as it did frequently) I would run around the building to dozens and dozens of workstations until I found the user’s workstation that had been the first to run the ERP after the server process crashed, and thus had the daemon running on their workstation. Then I would kill it, and sprint back to the server closet to reopen the daemon before any other users would run the ERP and grab the daemon (later would just RDP after we got off NT).
It was awesome.
My first professional programming job was working on a bespoke ERP and industrial process control suite (written in PowerBuilder). The program had a huge number of sub programs (dynamically loaded modules, each an MDI window accessed using a “program name”, something like a SAP transaction code).
We had a number of background services that would have to run, however writing Windows services in PowerBuilder was anything but easy. And we were reluctant to use anything else - the whole benefit of using a 4GL was a well integrated ORM and report generating functionality.
So we’d implement our background services as regular modules (with their little MDI window) within the main thick client app. Clients would have a number of workstations dedicated to running a single one of these processes. Nothing headless, each outputting it’s status or logs to he connected display. If the power, network or database ever dropped, each of these machines would have to be restarted and have its allocated sub program reopened.
For example, despatch label printing program would monitor a database queue table for new rows, bring up a report associated with the specified despatch note, print the report to the label printer then delete the row.
It seems so hackish but it worked incredibly well. Our clients were all food or paper manufacturers, running 24/7. Operations were rarely disrupted. Have a single screen per function to monitor for status changes was something operators were accustomed to.
This was over a decade ago, but I’ve never worked with a more productive team since. The constraints of the system let us focus on solving business problems. I can’t imagine writing anything of this scale in a modern environment. I’d love to see 4GLs like this make a comeback. The first class GUI, ORM, report generation were a huge productivity boost. And the simple programming language (with a very simple object model) put the focus on problem solving and not API acrobatics.
Simpler times.
The less information you have per screen/interaction, the more you lock users into a specific way of doing things. Business software users tend to optimise for what works for them. The worst UX experiments I’ve conducted in enterprise software involved low information density screens, showing users just what they told me they needed to see. User expectations in this space are so nuanced - better to favour more information and a high learning curve vs easier to user but less flexible software.
This worked great, except if we wanted to work over the weekend, since if we left the screen alone for more than a few minutes, the screen lock would kick in and we'd lose the session.
Our solution? We purchased a small fan with an oscillation mode, and tied a mouse to it. We then had the fan drag the mouse ever so slightly back and forth whenever we wanted to step away from the remote session. Kept it going for weeks.
$ws = New-Object -COM wscript.shell;
while($true){ $ws.SendKeys("j"); Sleep 60;}
Ive used it for demos that way the computer doesnt lock before the demo starts, its pretty short and easy to remember. Also on windows if you spam SendKeys("{Left}") everything you type is backwards and when you hit the windows key it freezes the computer in an interesting way, pretty fun.
Use it all the time when working from home/moving around and I don’t want my laptop to lock every 15.
Or a powered turntable for your mouse, if you can't plug HID devices into your machine! https://www.amazon.com/Liberty-Mouse-Mover/dp/B079P592K8/
function mouse_around {
while true; do
sleep "$1"
xdotool mousemove_relative 1 1
xdotool mousemove_relative -- -1 -1
done
}
mouse_around 60https://www.schneier.com/blog/archives/2009/08/risk_intuitio...
We used one of the common Raspberry PI Human Interface Device (HID) Python packages to send a harmless keyboard or mouse event once every 5 minutes.
Honestly, this story was told to me by an SAP consultant. I do not think he was an avid reader of BOFH. I might be wrong though.
Either way, I think this approach to avoiding bikeshedding has been invented independently numerous times. ;-)
most of the other game dev dirty trick on gamasutra are good value -- the "(s)elf-exploitation" one from Jonathan Garrett, Insomniac Games is particularly awfully clever:
https://www.gamasutra.com/view/feature/194772/dirty_game_dev...
I didn't have the guts to remove it.
Upon opening the code I discovered the entire program was a carefully constructed slide show with hundreds of jpgs in a jQuery carousel and some magic click areas coded in to jump the user between slides. Other than this code to jump to specific slides, there was no code at all. Even the text on screen was in the images.
I should note that their git repo consisted of about a hundred folders whose names were dates, and one folder named “current.” That was actually my first warning of just what I was getting in to.
Based on my narrow understanding of "standard issue practices" in car dashboard UI:s workflows, this was a common pattern at least at one major German automobile company. Static views and transition rules between them.
I was a bit involved in dashboard software a decade ago and was really surprised to learn this.
Phew -- this was not me.
TLDR: we had real-time order tracking with full shipping and billing integration in a tiny mail order bicycle parts business in 1997.
To be brief, their app ran the Android native camera app in the background and took a screenshot of the resulting feed for the image, bypassing actual integration with Android's camera apps. Having worked on an Android smartphone from the ground up, I can understand their reluctance to commit dev time to having to support so many Android versions and other variations on all the devices out there, but still a lazy weird hack.
https://android.gadgethacks.com/how-to/fyi-why-androids-snap...
https://www.reddit.com/r/GooglePixel/comments/64xqv0/snapcha...
Making a screenshot was way easier and since I didn't had to spend time to figure out how to use the bitmap API and its edge cases. Especially large pictures on low end devices caused crashes.
Turns out that it was a memory issue and every time I minimized and maximized the app, part of the memory got cleaned up. So as a temporary fix, I just wrote a script to auto minimize/maximize the apps on all boxes until we found the memory leak.
Note: we never found the leak.
If that sounds unlikely to you, it sounded unlikely to me, too. I wasted a lot of time trying to figure out where they were defined. I couldn't ask the original author of the code; he had moved on.
Eventually, I found them, sort of. They were being defined by a sed script that ran during the build process. It read the sources before they got to the compiler, constructed class definitions on the fly, and injected them into the code before it was fed to the compiler. So the definitions were right there in the code that the compiler saw; they just weren't anywhere in the code that humans could see.
Why was it done that way? I have no idea.
Sometimes you have to get the job done in a "less than ideal" way. But a lot of documentation/comments should be left to justify and more importantly explain how it works.
// This %thing% was generated from %template% using data from %data%.
If your language is too restrictive to add sensible tools, you should write the tools yourself. As with any code, write it in a way such that other people will be able to understand it.
There is no magic, it's just code. I wish people would stop using that word.
Where would you and the comment in a situation like that one?
I don't have anything against generated code but it should be visible and, as you said, it should be crystal clear where it come from
If the class is being used, then the definition has got to be somewhere, hopefully in a header. It's simply a file that is included somewhere. And it will be human readable. There is no magic.
That being said, I usually work in Scala which provides language-based tools for that, so it definitely helps with avoiding the "dark magic" sentiment you may have had.
But why was it done that way ? It reduces boilerplate, copy-paste errors, code duplication, in ways sometimes not made possible by inheritance or composition.
And it’s even better: you can define, augment, redefine or remove classes at runtime.
Light boards these days are just computers with some domain-specific IO. Tired of our ancient ETC Expression console, my colleagues and I wanted to start using ETC's new Nomad control software on our laptops. Our venue's dimmers only understood ETCNet2, while Nomad could only speak the newer ETCNet3 (and a few other open standards we couldn't use). Attempting a software upgrade on the dimmers themselves seemed incredibly risky. To bring Nomad's output to DMX would have required an additional $500 hardware purchase on top of the already-not-cheap software license.
On the message boards, I discovered a strange fact. The ETC-branded DMX<->Net2 interfaces we owned were actually white-label manufactured by a company called Pathport. Pathport boxes spoke a much wider array of protocols using the same hardware. These things handled firmware updates by flashing themselves with whatever was served to them over BOOTP. Pathport firmware images were free to download straight from the manufacturer.
Net3->Net2 was too much to ask for, but they could do ArtNet (an open standard) to DMX. Nomad could also emit ArtNet. So I flashed and configured one node to operate as ArtNet -> DMX, and plugged it into another node configured for DMX -> Net2.
So now, locked in a closet, there is a very strange loop of switch -> hacked ETC box -> normal ETC box -> switch which seems bizarrely redundant, but actually makes the world go 'round. And I could run lights and sound from any network drop in the building.
We didn't really have a budget, just some hand-me-down equipment that came from above sometimes. I and others on my team put together so many hacks to make things work. One memorable time, our light board had broken, but we still needed to run shows.
We didn't have enough time to wait for shipping on a real USB->DMX adapter, nor budget for a new board, so I created a hacked together DMX adapter with a serial to USB adapter and a NAND gate (I put schematics together here, if anyone's interested: https://github.com/magmastonealex/DMXAdapters).
It worked remarkably well for being a bit of a hack, but paired with software like QLC+, had more features than our old light board! It was still in use for controlling special effect lighting when I left, though thankfully not for main lighting and day-to-day use.
This also reminded me of how when HES stopped supporting the DP2000 in Hog, DP2000 owners just swapped it over to ArtNet mode.
Found a way to hook the vertical blank interrupt (shades of old Atari 8-bit programming), push all the registers onto the stack to create a setjmp/longjmp-ish way to call our physics thread at a consistent 30Hz. (OK, 29.97, but close enough)
Original dev boards were 3 full length ISA bus (IIRC) boards and were a PITA to get installed, all the IRQ conflicts resolved, etc. Later dev environment was a "blue PSX" (basically a production PSX with blue plastic that could run non-copy protected discs). I think the ISA boards had more memory than the production boxes; I'm not sure if the blue had extra RAM or not.
We were always RAM constrained (may have been less of an issue for a ground-up game, but we were porting a PC title), and we wanted to use a common codebase with the PC title, so we had a LOT of complex C macros to bridge between the PC world and PSX world. (As just one example, we could have used filenames on the PSX, but there was no reason to waste the RAM, so I wrote macros to turn PC-file-based accesses into PSX-sector-byte accesses. I also wrote the macros such that they'd break the PC compile/runtime [depending on the macro] to prevent the PC teams from writing code that would only work on their platform. It wasn't hugely popular with some of the "old-timers", who viewed the consoles as a distraction.)
Compiler was gcc; we used Emacs as our editor (me and the other main programmer were MIT alums) and in order to get a better emacs experience, we installed OS2-Warp as our desktop OS (so we could get subshell compilation working, which didn't work, or didn't work well on a DOS boot [this was 1995 and prior to NT-based flavors of Windows]). Debugging was primarily via printf or small graphical blocks on the corner of the screen.
Documentation was fairly terrible and Sony CA had to escalate many clarification questions to Japan. Docs would say things like, “It’s critical to never fail/forget that initializing this system must happen strictly before the lack of initialization of that system.” It sometimes felt like the Ed Asner water-in-nuclear-reactor sketch.
Sony QC to approve the golden master was very strict. We shipped with over a dozen tracks and they seemed like they drove every square inch of them and complained about graphics glitches in many places that were far enough off the racing line that we never noticed (or never cared).
In terms of graphics "flair", the PC title had a flat colored track, which wasn't as appealing as the PSX titles of the day (Ridge Racer and the like). We didn't have a huge art budget for the title, but we created an artificial racing "line" of darker track which we placed by repurposing the position and acceleration data used for the PC AI drivers' algorithm. Where the AI cars were accelerating (including laterally) was darker than where they were just driving was darker than where they rarely drove.
Because the PC title was heavily focused on realism (which means it's not as easily accessible or "fun" for the casual gamer), I created an "arcade physics" mode where the car would slide and rotate more, had higher absolute cornering and braking ability, but the same forward acceleration. I also added "double click to burnout/do donuts" in normal mode as both a fun way to screw around but also a way to more easily exit a tight pit box. This had the unfortunate effect of giving much better acceleration from a standing start. So, when it found its way into the PC multiplayer title, standing start races became a sea of tire smoke and cars running into players who hadn't learned that burnouts gave faster acceleration. (We properly modeled the horsepower as a function of RPM. Burnouts raised the RPM. My hack didn't model the tire slip under acceleration, so burnouts brought the car up into the power band and you would walk away from a car who was accelerating from a lower RPM.)
We had another team working on a Sega Saturn version at the same time; that title never shipped, in small part because of the technical hurdles of getting the title to run on the platform, but also because of the limited commercial success of the Saturn was becoming obvious during development.
Other memories were working with some of the most talented programmers and artists I'd worked with up to that point in my career (both on my immediate team and elsewhere in the company), meeting Ken and Roberta Williams (Sierra bought us), and going to racing school to get a better hands-on feel for auto racing. Fun times and I sometimes wonder how my career would have gone differently if I'd stayed in games. (I left because each successive merger or acquisition by non-gamers made the company worse and worse to work for. Sierra and the Williams were great; subsequent MBA-types were each progressively worse, including substantial securities/accounting fraud so I was glad to get out when I did.)
Random tidbit: it was a single player game. If you pressed a button on P2 controller during boot, we had a simple light cycles of Tron type game embedded as a small Easter Egg.
I was tech lead on the PSX title and contributed to the PC NASCAR Racing 2 and Grand Prix Legends title. Many of the core programmers from Papyrus went on to form iRacing.
I seem to recall that the DOS titles were 4GW. We ran the physics and joystick read (time a capacitor charge through a variable resistor in the controller) together (and maybe the sound synthesis as well)
(We had hacks to detect running under Win95 and then walk the app, touching each page periodically to keep Windows from paging us out.)
Among the many functions this server has was to host a bunch of black and white x terminals. Probably only a few people here ever used those (although more than most other online forums!), but basically the idea is that they plug into the network, at power on they tftp down the image for the x server, they boot and allow you to run x client apps on the server, an 80s thin client implementation. So we upgrade the server and things are working pretty well, especially for such a major upgrade.
My boss/mentor at the time is truly brilliant, so we really had most everything thought of. The only thing that was off was that all of a sudden the xterms all stopped booting. We couldn't figure it out. Network sniffers didn't show anything useful--we were just baffled.
On a whim, we decided to take the tftp server out of inetd control and truss it (Solaris equivalent of strace). The first time? Worked perfectly--our test xterm booted just fine. Eventually we figured out that the new server was so fast that the speed of the tftp transfer was triggering a problem on the Ethernet card firmware of the xterms and by using truss, it slowed down the transfer and bypassed the bug.
Solution: In inetd.conf, we just spawned in.tftpd with "truss -o /dev/null". Never saw the issue again.
So real data center, racks, etc. But this cheap ass, caseless, P90 on a shelf with a household fan blowing on it, while making millions of dollars.
I was mystified why there was no budget to use a real 1U server. The internet was pretty new at this time, but it was driving revenue.
Also, side info, this caseless P90 still exists. Sitting in my friend's cubical, naked and caseless. Pure glory. It's a hero. Tech stack was NCSA webserver, C, and Ingress plus daily updates with a 1.44MB floppy disk.
I was told in no uncertain terms by the client that I had to fix the server hangs within 48hrs I'd lose the contract. This was in a million+ LOC custom Wordpress nightmare.
I wound up writing a script that ran on a little EC2.micro instance that would ping the homepage every 60s looking for the HTML comment `<!-- if you delete this comment, the server will reboot forever -->`, and if the request timed out or the text wasn't found it would hit their hosting API and reboot the server the site was running on.
I deployed the "fix", finished the contract without incident, and subsequently fired the client.
I imported the spreadsheet into google sheets, gave him access, and had the webserver paste the values in the spreadsheet via the google sheets api and read them back out.
https://github.com/franciscop/drive-db
Since you can also hook a Google Form to a spreadsheet, you can do surprisingly advanced things over there.
You can do all sorts of interesting things between a form, spreadsheet, and other services including your own. Nobody seems to use it, but internally we do all sorts of gloriously hacky workflows with it.
You can easily script forms/sheets/calendar/Gmail together to create pretty much anything you need.
I use it to send daily email reports of data fed into a spreadsheet.
From a quick overview it seems like if you need serious work with spreadsheets/GDocs then App Scripts is a good choice. However drive-db is more like a (very) quick way of putting a Spreadsheet into your Node.js backend as an array/db. I purposefully didn't even allow edit since that'd require API keys from users and defeat the quick part of it.
Sounds more like some BS requirement from a clueless middle manager or a boss and a dose of malicious compliance.
Do you see that plain-looking dropdown menu with the rounded orange highlights? That is Internet Explorer. Just this one menu. It's an in-process instance of Trident, IEs old HTML rendering engine. So that little window is the equivalent of somthing like chromium embedded. I don't know why that menu is an instance of IE's HTML renderer. Someone wanted to style it with CSS, I think. So they embedded IE. That flyout to the right is probably another Trident window. In order to meet accessibility requirements, I had to grab the running instance of the root IE COM interface, and route keyboard events into it. With raw C++ COM. There were other hooks going in the opposite direction so the menu / browser window could tell the app about clicks.
After a while, I discovered that the issue was about web server's ethernet card attached to internal network and used to connect MySQL server. When that ethernet card stops working, the platform would crash. On the other hand, it was also possible to connect to MySQL using the other ethernet card via public IP. It would reduce the performance of the platform, since all the bandwidth of that card (100 mbps!) is already eaten by HTTP traffic, but at least it would keep it running.
I ended up writing a script at my home computer, checking if the platform is up or not. Once the faulty ethernet card fails, it would connect to FTP, change PHP configuration to use the other ethernet interface to connect to MySQL server, and send an e-mail to datacenter technicians to press restart button.
This script successfully did its job during 3 months, until I eventually replaced the faulty ethernet card and fixed the issue.
Isn't it "Invent and Simplify" like Jeff Bezos says?
That ‘if’ block exempted me, the CEO and the CMO from traffic limits (which at the time would forcibly disconnect you) and make sure we had 24/7 access (I had set it up during testing because they kept calling us to remove the blocks, and one night I couldn’t log in either).
We found out during that exchange that another former colleague had left a cron script downloading Dilbert and User Friendly comics that had filled up the hard disk since 2008 (the machine had nearly 12 years of uptime).
Solution? A bash script that does:
while true:
set date to 4pm end-of-year
sleep 1It needed to be end of year day for 2 or 3 days.
Three lines of bash seemed simpler. It's a hack, yes, and there are better ways. But really who gives a damn.
Some code read xml data. Instead of choosing one of the xml-parsers available, author decided to write another one. Instead of using C++ features, atoi() used. For empty strings, atoi() got NULL and segfaulted. Signal 11 has been handled and suppressed in order to avoid crashes. Certainly, the code had other segmentation faults too, which could not been discovered this way. :)
It was not possible to read this particular cash register when it was in operation mode OR if it was in OFF mode. Also we did not have access to GSM sims and there was no WIFI at stores.
SO:
We installed 56K modems and plugged them into the regular PSTN lines.
BUT:
That would interfere with customers calling to order out.
SO:
We plugged them into analog plug timers and only had the modems switch on between 5AM and 10Am.
AND:
The store owners kept switching Off the tills. So we had to disable the off position for all the tills.
The backend was a VB6 app running a 56K modem that read each till in turn and then processed all the results.
Ran for 11 years with not much bother.
[1] - https://en.wikipedia.org/wiki/Fast_inverse_square_root
The legend himself, John Carmack.
Fast inverse square root is really the perfect example of black magic in programming.
Unorthodox technique, that you can explain if you try hard enough (in a sense, everything that reliably work could be explained and someone has to came up with in the first place), used by people who don't really understand it.
What do you think is a better example?
“A Story About Magic” is black magic in action. http://catb.org/jargon/html/magic-story.html
“The Story of Mel” is not black magic even though no one else understood his program. http://www.catb.org/jargon/html/story-of-mel.html
In the world where FizzBuzz is hard, applying the Newton Method is a rare thing.
When Windows is configured in a very high security manner, the user needs to manually give our application permission to use the certificate once during the lifetime of our process.
We hit a bug in .NET where, if we start multiple HTTP requests at the same time that use the same certificate, and the user needs to approve our use of the certificate, the user will get multiple request dialogues.
The fix is a very convoluted lock statement, because if the user says no, the other HTTP requests that would be started at the same time need to be aborted.
What makes the lock statement more complicated is that we essentially need to lock right before the HTTP request starts, but then unlock when we are reading the stream. This means that the first time we use a client-side certificate, we have to disable multi-threading until we know that the client site certificate is approved by the user.
So naturally, it now runs strace >/dev/null in production, probably to this day.
Not only this, but he failed to inform the onsite crew that was going to put it in production.
AGV went somewhere it wasn't supposed to go, first employee pushed the red safety stop. AGV kept on riding, and thank god there was another person at the electonics panel to make it stop.
I was outraged about this, said that someone could have died, and that could mean jail time for the CTO. They said I was overreacting, and continued on their latest project that involved an AGV carrying people in an amusement park. I quited after that.
Problem was that it didn't want to move because of wrong interfacing of the safety system. So the solution was quick.
Solution: Arduino and a relay in-line to cut the power for 1 minute every 120 minutes.
Planned to add a DS1820 to only cut power when required, but never got around to it.
1. Generate the page chrome 2. Post that HTML into the database 3. Call the new framework 4. Pull the page chrome out of the database 5. Render the page
The worst piece of the VB6 code I ever had the misfortune of working on was an implementation of a questionnaire, which would guide you through several pages of questions and keep track of what the state of the questionnaire was. A particular sequence of actions could crash it consistently, but the code was so incredibly stateful that it was impossible to work out what was going on. To add insult to injury, it didn't happen when debugging, and the VB6 debugger left a lot to be desired anyway.
What do you mean you refused to take over? You refused to continue “hyping” the undeveloped feature?
I had just joined a “subscription based social site” as a backend developer. I think it was PHP 4 and MySQL 3 at the time.
Someone had realized that it would be great to have database “migrations” in code instead of using phpMyAdmin to modify tables.
Thumbs up, forward thinker!
So there was an ONE BIG migrations.php file that had our DDL in it with if statements around each one to see if it had already been run.
The statements didn’t have a version number or anything super simple and trivial. It was a combination of all the worst ways you could figure out if a column had been added to a table in MySQL.
When code was deployed, someone would visit http://example.com/migrations.php real quick to migrate the site.
Oh man, classic.
Application A is multi-threaded, huge, hardly maintained. It also constantly crashes. Would've probably taken a few ace C++ programmers quite a while to iron them all out.
Solution? Write a custom watch-dog application that restarts it once it crashed. (This was on Windows, and a while ago. Being a *nix guy myself, I've no clue if something -available- like daemontools could've been used back then).
Let's say I didn't know whether to facepalm or stand in awe.
https://www.reddit.com/r/Cartalk/comments/10cwhb/til_how_to_...
He happened to have clamps in the back, put a clamp on it and a few rubber bands for good measure. When he finally got to the garage they looked at it, laughed, then suggested that he keep it that way, given that the parts for the car were rare and the fix was reasonably expensive. I believe that he ended up driving on that for a couple of years until the car broke down from an unrelated part failure.
In the 2016 HN thread "Strange bug workarounds" I posted a much gnarlier problem (and oddball solution): https://news.ycombinator.com/item?id=12485921
(I often check the posting history when someone posts something interesting.)
So I ended up with a server serving the editor frontend, as well as api endpoints that would use puppeteer and headless chrome to make a request (to itself) to load the frontend, import a given label file, render it, take a screenshot and save it to a file, then reply to the api request with the contents. So kind of a recursive api.
I had so much fun with this but I still can't believe I had to write my own svg editor and bake my own pdf generation and merging code to get the job done. It should not require two languages (node and python) and a headless browser to get the job done.
It's super weird, and I've been over it from every direction but I don't know how I could have done it differently.
this is exactly my question: why did the pdf generation need to be server side?
We certainly could do the work on the client, but they're making this request in a context where neither the label nor the libraries need to be loaded; in fact, in our server-side implementation, it could be done with a single api call. Doing it all client side would strongly couple the client to the technology.
Also, we re-used this api in two applications, one of which never loaded the editor (along with its dependencies).
TLDR; a weird hack was better than violating separation of conerns.
is the printing service a real physical service?
anyway i'm doing basically exactly this same thing except all client side (i send the serialized "label file" and data to the client) but printing is being done using the user's printer
The reason we did it this way is 1. we have a web app so we can't print directly to their printer without a print dialog, and 2. we want to print to potentially a different device than the user is on.
I was hired because the regular firewall/security sysadmins resisted installing tooling the director wanted that would allow them to be effectively 'monitored' doing their work on the firewalls distributed worldwide. In particular the director wanted to use Tripwire to alert when files were changed on the firewalls. He had tried to push this through 3 times before and each time it was rebuffed/scrapped one way or another.
As I went through the testing phase I took careful note of the security issues I found. When all was done I had 2 big holes I could not easily close. The first one was that from the management server (a simple Java app) you could click file/open and using the explorer window you could 'run' explorer.exe thus opening the Windows shell/GUI (as well as run command.com, notepad.exe). I closed all these with file permissions and other settings.
The final one was much harder though. You could, using the same file/open explorer window, open the log files of the GUI (with a notepad like functionality), and alter and save the logs again without notification (non-repudiation violation). The user account had to be able to write to that log for the entries to be created.
My solution was to create a long-running script in the background that would cat and empty all of the log entries every 2 seconds to another file location further limited by tight permissions only to the script account.
I deployed this in production for over a year and to my surprise it never stopped running (or more likely I thought, overflow and/or lock up the system).
My worst kludge...
It was a highly optimised sorting algorithm for client names, and used everywhere. It occasionally dropped a name, and I was asked to fix it.
PL/I allows you to free part of allocated memory. In this case, two names would be pulled out of the array, that part of the array would be freed, and turned into a new array instance. Pair got sorted and reinserted. Repeat until array becomes array of single arrays, then bitshift edge of array allocations to recreate array in place.
It turns out that when the costly printer was purchased, there wasn't a Mac OS driver available for it, so the people who installed the LAN created their own homemade print queue management system, relying on a batch file running permanently in that one Windows client. The batch file would take .eps files, saved on a shared folder by the Mac clients, and send them to the network printer using Windows printer drivers. Whenever that Windows client freezed, was reset, or was powered off, printing to that one printer would stop working for all the Macs at the same time.
Backstory: we produced a custom software that used Windows Embedded' LDAP library to handle the LDAP part (Winldap32 library with the Winldap.h headers). The machine running our software didn't join the domain, so it only authenticated the users with the ldap_bind function.
If I recall correctly, we found the ldap32 library referral problem when we used AdInsight (by Mark Russinovich) and saw the library was poking all around the place (the other forest DCs) and never completed any of the requests. I think we confirmed with Wireshark.
The hack was in 2 parts:
1) We made a DLL that offered the same ldap_* functions as those we used in our software. The library then redirected the LDAP calls to a python script that used a native ASN1/LDAP implementation which relied on nothing but pure python code.
2) Then we made a injection software that injected the DLL in our software at startup and replaced the Winldap32 functions with our DLL functions.
We then were able to bypass the MSFT' LDAP library problem, and I think we pretty close to our initial deadline in the end. Apart from the (very small) added latency on LDAP code, everything was fine in the end.
We need to solve the riddle if it was wifi or laser link.
Does 802.11b support this magnitude of distance?
Interestingly enough as recently as in 2016 none of the browsers' devtools were prepared for such a usage and would hang if you set a breakpoint inside any of the "tried" functions.
I worked in a vehicle assembly plant from the mid to late 2000s, and our real-time monitoring was performed with a commercial off the shelf system called Cimplicity. Cimplicity was an excellent systems integrator... for the 1990s.
Cimplicity's main problem was that it wasn't enterprise scale; updating the content of screen objects was laborious.
Someone's solution was to add a database call to every object on the screen - some screens had about 100 objects.
So on each and every screen startup, on each and every computer, about 100 database calls were made.
---
I guess that wasn't too hacky, but when absolutely everything is half hacked together like that, it's hard to what is a hack and what is normal.
I was building the client library (wrapper) of an old external third party service we were running, for the our new system (re-write).
By the way, this old third party supposedly has REST interface which was added later, when REST was getting popular. So I needed to get all ABCs but couldn't figure out how because there wasn't any `GET /abc` for ABC but `GET /abc/<id> on the docs. So I just checked how it was done in legacy code.
Then I found a for loop 0 to 100 which was doing 100 `GET /abc/<index>`. It was working because ids were incremental and there were only less than 50 ABC records. Unfortunately there was no caching or `break;` after `404`. :(
Luckily the ITSM system I had took incoming and outgoing email. They had a stored procedure “hook” for email. I reimplemented the SLA functionality by inserting the relevant data into the database, calculated the SLAs via the procedure.
In my first professional job, we used PKI-encrypted email as a transport for ebXML messages (order, despatch notifications, etc) between our customers ERP system and their suppliers. And in my most recent role, we received retail transaction data and returned analytics reports via email.
The great thing about protocols like this is that virtual all enterprise systems support them in one form or another. And it’s always been easier to get clients to set up exchanging data via automated emails vs SOAP or REST APIs.
I think they're called lpr and lpd. But I've tried to find their source and it's not in any major printer packages. By running strings and hexdump on them I think my co-worker finally managed to trace it to a package of software made for a firewall. And embedded in there were these two programs for printouts.
SO that became well used in a major government branch that will go unnamed.
Fast forward to 2013 and it's my job to upgrade it. Replace its hardware and its OS.
Luckily the two binaries could be run from RHEL 6 but it was all on faith. I had no way to replace them or upgrade them because I had no idea what they did, what protocol they spoke.
So they're running to this day. I'm sure someone here who is more versed in printing might tell me that they implement some standard protocol that can be replaced by CUPS or something well known. I'd be thankful but tbh they work so they won't be replaced in my time with these systems.
Typing `mkdir foo:bar` in my macOS's terminal leads to a directory, that Finder shows as `foo/bar`.
Was the lead software and computer engineer on a new robot. We had decided to use compact PCI, which was at that time (late 1990s) a brand new form factor, so a lot of specialized cards weren't available for it yet. But that was OK, because the manufacturers were selling bridge cards that adapted smaller form factor cards to the compact PCI standard.
One of the cards we needed was a motor driver card. The particular card that was available to us used an LM629, a very old, widely used, digital servo controller chip. Now, whichever guy or girl designed the LM629 was an anal bastard. The chip had memory-mapped read-only and write-only registers, which was fine. But if you ever read or wrote anything out of order, or tried to read a write-only register or write to a read-only register, the chip would drop into an error state. So the device driver had to be right on the nose, the chip wasn't going to cut you any slack.
Because the cPCI standard was so new, I ended up writing the device drivers myself. Which was OK, I had just graduated with a CS degree, knew metal-level C pretty well, things should have been fine.
Except I couldn't get this motor driver card to work. Every time I tried to command the motor, the chip would generate an error. I stripped the code down more and more and more, to the point that I was only sending a single 8 bit write and then a single 8 bit read, and still the chip generated an error.
After two weeks of banging my head against it I was at the end of my rope. The manufacturer of the LM629 card took pity on us and let us bundle the robot up and bring it to their site, which was in Minneapolis. They gave us a small lab, where we proceeded to bang our heads for another three days with no progress. Eventually he took more pity on us and assigned us his digital logic expert for the afternoon.
Dude rolled in the most badass digital logic analyzer setup I had ever seen at that point. The thing took up a full-sized equipment rack. He hooked up to our board and asked me to issue an 8-bit write. That looked fine. Then an 8-bit read. He raised his eyebrows at that one - asked me if I was sure my code was correct, as he had seen a 16 bit read. The top byte of which was mapped to chip memory space we weren't supposed to be tickling.
I told him I was 100% positive that the code was not asking for a 16 bit read.
Eventually we ended up on the phone with Intel, which made the bridge card chip. They told us that their chip had a known bug; it couldn't translate an 8 bit read on the cPCI bus to an 8 bit read on the daughter card bus. Instead, it issued a 16 bit read and threw the most significant byte away. "This is documented behavior," they said. And sure enough it was, in a footnote in 10 point font on page 52 of the manual.
That left us in a quandary, since there didn't seem to be any way to fix things. Then we had a brainstorm. The fix was to cut the address lines of cPCI side of the daughter card and shift them all one line to the left, and tie the least significant address pin of the bridge chip to the most significant address pin of the LM629 address decoder logic. That way any attempt to access odd addresses got mapped into nullspace, memory space somewhere way above what the chip actually had, and the decoder logic just rejected the access request. The chip would never see it. Then we rewrote the code to make the new addresses line up with the chips newly re-jiggered address space.
Worked like a charm. We treated ourselves to a high-end steak house that night and flew home. As far as I know the robot worked in that fashion for close to a decade, until they retired it.
As a side note, memory issues were a huge problem that is largely invisible to most software engineering. To give you an idea on how complex the solutions are, check out how Naughty Dog solved this on Crash Bandicoot: https://news.ycombinator.com/item?id=9737156
Every minute of every host on the private cloud ...
... but I have come upon many strange problems in various EMC products so that does not surprise me a lot.
https://www.omgubuntu.co.uk/2018/01/xorg-will-default-displa...