• P (unregistered)

    TRWTF: that entire application is a plug-in to another software.

    Plugin-ception.

  • Anon (unregistered)

    Oh i really really hate this line.

    int briefType = int.Parse(form["reportId"]);

    I'd personally use var, but that's preference. But why use form[""] and not a specific class and also, the assumption is now that reportId will always be an int.

  • (nodebb)

    Even if you think a plug-in architecture would be useful... just stop and realize that even YAGNI. If you need to deploy a new plugin to production, you need to compile and deploy at least the plug-in anyway. With a proper CI/CD pipeline, who really cares that this pipeline has to recompile the calling application as well?

  • P (unregistered) in reply to bjolling

    Re-deploying the calling application means downtime in production. If you can just drop the plugin and pretend nothing happened will the application will be able to automatically capture the new plugin, that's the wet dream to many developers and users.

    Of course, the real issue here is that once you loaded a dll, it's locked by the application for the rest of its lifetime, so if you want to update the plugin, well... you need to shut down the application, replace the dll, then turn it back on. Or worse, if new threads are opened but they died for some reason (e.g uncaught Exception), now your plugin is locked by the entire hosting environment instead and you have to restart IIS server or the equivalent to update your buggy plugin. Basically it's dangerous as heck.

    How do I know? Well, I'm developing plugins for an in-house product that has exactly this kind of architecture...

  • Jaime (unregistered)

    If you make the site properly stateless, then re-deploying won't break existing sessions and no one will notice.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    This is my favorite kind of bullshit to hate:

    bool minute = "true".Equals(form["minuteBool"]);

    ...doing shit like "== true" to a boolean to convert it to a boolean. I think I'll call it... "boolean washing". Oh well, at least it's not the ternary form. Also, a boolean named "minute"? Does that mean mi-nute as in very small, or is it saying that some other value is in min-utes?

  • P (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    A boolean named "minutes" means if you're about a minute till you nut.

    You know, you can't spell minute without nut.

  • Brian (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    Well, if it makes you feel any better, they're not using some kind of implicit casting to bool there, they're comparing the string value of that form field to the string "true". Meaning that, that if the field contains any other value - "1", "yes", "True", "FileNotFound" - it'll evaluate to false. Which is, of course, even worse.

  • (nodebb) in reply to P

    I created such a thing as well. As it turns out, none of my clients use the application outside of business hours, so plenty of time for some downtime.

    A decade ago, I was working at big financial services company: they had a 4 hours downtime window after the closing of the stock exchange in NY and before the opening of the stock exchange in Tokio.

    But I guess, I could have started with https://martinfowler.com/bliki/BlueGreenDeployment.html

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Brian

    Which is, of course, even worse.

    Yes that's very "TRUE", and stringly booleans make me cringe even more. At the very least I'd want to abstract it out to a function instead of comparing with a magic string constant every time it happened.

  • (nodebb) in reply to Brian

    It's a web-based application, and GET/POST data can only be sent as strings. If they wanted to make it a boolean in the C# code, they'd first have to convert the string to a boolean, which of course would require defining what strings are true and what strings are false. I feel like we've had a few stories posted here about that topic.

    Also, if the form field is a checkbox or select list, then they control the value of the field anyway, so they can check for exactly that string.

  • (nodebb) in reply to P

    I don't have much experience with containers - yet, but would not putting an application like this within a container (Azure?) along with the proper infrastructure (balancers, etc.) allow you to redeploy the app without taking down a current instance? Once a new instance is up then the out of date instance could be taken down and restarted. If a deployment infrastructure had more than one server instance then could not the same process be used without containers?

  • (nodebb)

    BTW - FWIW, I had to do this very thing (call a JS method from Java) in a UI component (Swing desktop app). Yes, it couples the Java code to the JS UI code (running within a Swing window), but the JS code (a UI component itself) actually has the logic in it to create the data necessary for another part of the app UI to display the data in a different part of the app. Its a messy legacy app and this is a hack to integrate the JS UI into the desktop app. The JS code will be refactored later for a more conventional client/server/web client app.

  • Reginald P. Smithington (unregistered) in reply to bjolling

    You severely underestimate how many companies have proper CI/CD pipelines.

  • Tim Ward (unregistered)

    I once built an entire application on having the back end call JavaScript methods in the front end. Most of the time the front end sat there long polling and just running whatever code the back end sent it (mostly calls to functions to update bits of the view 'cos some event had happened out in the real world).

    It was all good fun and it worked fine!

  • James (unregistered) in reply to Reginald P. Smithington

    s/underestimate/overestimate/

  • Jaime (unregistered) in reply to Developer_Dude

    <quote>could not the same process be used without containers</quote> Yes. I've been doing variation on this theme for a very long time and it can be done with a single server. It frustrates me that the new technologies are sold to re-solve problems that have had solutions for a long time.

    I recently saw a desktop app get replaced with a web app "to reduce deployment problems". The old desktop app had an auto-updater and the update didn't require admin privileges - so it never caused a problem. The new web app was built by rookies and had massive script caching problems. Every update is followed by a hundred help-desk tickets, all resolved with "empty your browser cache". Good job.

  • bwldrbst (unregistered)

    Nice. I'm currently hunting a bug in a plugin just like this written about 15 years ago in VB.Net.

    Naturally our repository contains the source code for the entire system apart from the plugins.

  • (nodebb) in reply to Reginald P. Smithington

    CI/CD is the main topic of the first sprint(s) for any project I start. At the start, usually there is indeed no CI/CD but after a few sprints, we have functioning pipeline.

    Addendum 2019-12-11 03:12: One of my current projects is building pipelines for legacy Powerbuilder applications. It took months but we have now finalized them for about 35 interactive applications and the ones for about 35 batch applications should be done end of Q1 2020.

  • (nodebb) in reply to Jaime

    For production we currently have a desktop app pushed out to about 3000 desktops. This is going to be replaced with a web client. The web client will have containers for a number of different processes, but those are primarily for scaling purposes, although deployment is an issue with the desktop app - especially the issue of multiple users not updating and using older versions of the app. We look forward to easier deployment with the web client.

  • WTFguy (unregistered)

    @Developer_Dude: The WTF of your employer's desktop app deployment strategy is that users have any choice in which version they run. If the latest version is always force-pushed that problem goes away.

    Any user who would whine about that or try to circumvent force-pushed desktop version updates will be equally upset about your employer's new webapp. So clearly it is not a true "business requirement" that users be allowed to choose which legacy version to keep using.

  • doubting_poster (unregistered)

    Nobody commenting on the fact that they're loading all the DLLs then scanning types, which will trigger any static code defined in that DLL? A malignant DLL doesn't even have to bother with the endpoint interface, just put in any static code and wayho you've got application level access.

    And besides the security aspect, It only returns the first endpoint and never unloads anything. So you can't update, you cant add new ones and you can't remove any. Good jerb!

  • (nodebb) in reply to WTFguy

    Since the desktops are offsite users that are not within our org, forcing them to use the latest version is problematic. Generally it works out though - but can be a source of problems with some number of users are not up to date. Often we do not allow certain desktop operations that use our backend services - if the version is too old - so they need to update eventually.

    IMO - it is the deployment process, which is overly complicated and always causes problems, which is the real hindrance for productivity. Devs/et. al. are looking forward to using the web client instead.

  • Some Ed (unregistered) in reply to P

    It feels to me like the base problem is that MicroSoft only figured out a quarter of the magic to make libraries safe, and Unix only figured out a quarter of the magic to make libraries safe, but a very different quarter.

    Specifically, MicroSoft's mandatory file locks are, in many ways, useful, but they have a fundamental failure point on the update issue, as you implicitly note. Unix's ability to replace a file with a different one without afflicting anything that still has the old file open is extremely useful. But Unix's lack of protection of files that are opened as executable code is extremely bad.

    It feels to me like things would be much better if the mandatory file lock applied to the file pointed to by the inode (I realize that MicroSoft doesn't use inodes. MicroSoft is a collection of human beings, which means their intelligence is fundamentally limited just like all of us.) rather than the directory entry for the file and everything that it represented. This would mean you couldn't modify a file currently being used as a code source, but you could replace it with a new version. The programs that were running from before the update would continue using the old code, as if no update occurred, while new programs would get the new code.

    This wouldn't fix everything. But it's something that either side of that disagreement should be able to do, as both technologies have been around for more than long enough for any patents to have expired. (The unix side of things has been around long enough to have never been eligible to be patented, even, if I'm not mistaken. Of course, a concept being around for more than 20 years before software patents were a thing didn't stop MicroSoft from patenting IsNot, so what do I know?)

    To be precise, the remaining problems would be figuring out an upgrade process for the existing processes, and a method to work with those processes until then. If only there was something like VMS versioned files...

  • tlhonmey (unregistered) in reply to P

    So it sounds like what you need to do to deal with the file locking issue is just have a staging area for plugins. The framework moves the dll from staging to a live storage area, and then loads it. If it ever notices a new dll with the same name in the staging area then it can use that as a signal to unload the dll, replace it with the new version, and reload it. For complicated systems it may require a bit of dependency metadata or manual intervention to know what it can unload in what order, but it should be perfectly doable in any language that allows libraries to be unloaded.

  • just some guy (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    At a guess, since it's creating a document, and there are references in there to "brief" and "dossier", it's a legal system and that boolean tells you whether the document is a minute or a letter.

    https://en.wikipedia.org/wiki/Meeting_minutes

Leave a comment on “An Endpoint's Plugin”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article