Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "back to banging my head against this"
-
> Bang head against issue for days
> Finally get help from lead
> Watch them bang their head against it on video for 40 minutes
> Watch them shake their head in disbelief at how difficult to follow and objectively wrong the existing code is
> Talk through approach to fixing it and patching in the new functionality
> Listen to a short recap
> Ask question, get answer
> Chat about next company meet
> Meeting adjourns
> Jot down implementation notes before I forget
> Remember answer to question, forget everything else
FFFFUUUUUUUUUUU 😭7 -
!rant from a support guy
I was tasked to migrate an Exchange 2003 server (yes, those are still used) for an upcoming Office 365 deployment. There are no direct upgrade path from one another, as far as we know
My task was to export PSTs from mailboxes. Great, a native tool exist for that in 2003 (exmerge). But only for less than 2 GB mailboxes because ANSI/Unicode! Half of our mailbox busts that limit. Oh, it seems Exchange 2007 has a PowerShell command for exporting to PST as well! But pre-SP3, that command relies on a local installation of Outlook on the server (DAFUQ), and has been superseded by another "standalone" powershell command. So I install a bogus Windows 2012 server only for that purpose, with Exchange Management Tools (which, by the way, is bundled with the Exchange installation setup and REQUIRES to have IIS installed on the target machine. Also, if you install ONLY the Exchange 2007 Management Tools and wish to uninstall them afterwards, you can't because the uninstaller wants me to select an Exchange Role to remove, which are all unchecked in my tools-only setup). Never worked, and Google-fu says that the newer Exchange 2007 New-MailboxExportRequest command seems to have removed Exchange 2003 support.
So i'm back to installing a pre-SP3 Exchange 2007. Then the older Export-Mailbox powershell command whines about 64bits and 32bit incompatiblity-- actually I ***HAVE*** to have the whole OS/software stack 32bit ONLY. Don't ask me why!
Some article I found says I could fire up an XP virtual machine for that, I go for Win 7 x86. "Sorry, Microsoft Exchange won't be installed on a workstation environment because reasons." All right then, let's go for an old Windows Server 2003 x86. Have you tried to boot this up in an Hyper-V environment where mouse and keyboard support for Windows Server 2003 are apparently optional? No keyboard AND mouse events sent to the guest machine at all.
* Sigh *, let's use a Windows Server 2008, but WATCH OUT! Microsoft has discontinued x86 support on their W2008 R2 release, so non-R2 for me. Even then, mouse event wasn't sent until I installed guest additions.
After all, export-mailbox ended up working, but that costed me two days of banging my head against the wall. (Oh, and I take internal calls inbetween as well...)
And that's why I aspire to be a programmer. Thank you for nothing, Microsoft!4 -
I wasn't happy with one of our UI views for editing a database query that consisted of about 50 fields ("editing" being the operative term here, not just viewing. It had to be two-way). Everything was hardcoded and defined manually, with each block of ~10 lines being repeated and mostly identical apart from the occasional double inline field and name of the variable. It had "just ended up that way" over time due to the variable names in the UI being different than the names of the variables that came from the API.
I decided to overhaul it all where I defined the different input components and which fields should be included, then made a function which would generate the page based on these definitions. It was about 500 lines of modularized functions and classes where the class for the actual view was about 50 lines- compared to the 1400+ lines of the previous version.
But, it didn't work. It should, but it "just didn't". There was no error. All I got was a blank, solid white page. I could make a drastic change or try something completely different and I would get the same error, same blank page. API fetch succeeded, value assignments succeeded, the object exists, but if you iterated it it was... empty.
I started getting really discouraged that I had made it too abstract. Maybe I actually made it more complex and unreadable than before. Maybe just hardcoding it all was the better solution after all. Maybe I had gone against KISS and overdesigned it.
I was up pretty late and everyone had gone home. When the last guy left there was that mood where "yeah if I can't make this work we'll just use the current version...".
Turns out I had tried iterating over a property of the set of fields to render, rather than the entire collection. In the old method the variables were a member of an object, but now they were its own object, a change I had made to isolate the set of values which were to be viewed/edited and make them easier to pass back and forth. This member existed since I hadn't cleaned it out yet, but it was empty.
I had been banging my head against this for a whole day and I was ready to admit I had made a mistake and wasted my time before discarding it all, but then I backspaced this one property and the interface went from empty to rendering perfectly and with all functionality intact. I swear god rays were coming out of my screen.