- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I bet someone sold that to management as, "Now we can keep accessing our SWIFT codes, even if the database is down!"
Admin
Hey i have an idea, if we just hardcode more data into the code, then it can be versioned!! I bet you didn't think of that.
Admin
regretfully I have something similar in new services I am putting out, and I know it is wrong but it is the lesser of many evils. The problem I have been faced with is not how to code, how to put a table together or even the format of the data it all comes down to process. If I just have a service that returns these values, I only have to work through the red tape for two weeks to get the change approved for production after all the coding is done, unit tests are performed and UAT testers sign off on it. If I add a database to hold these values this process can take up to 6 weeks or more as we then have to work through security values access to database tables, requests for update to the data, and full reviews each and every time. Business complains each time about the length of time this takes and has made it a requirement that we get things out the door faster. With our process there was only one way to do that, get rid of the database.
Admin
You have two problems - database access and meeting customers needs. Remove the database. Now you have only one problem!
Admin
Time to use Regex!
Admin
Personally I don't think its to objectionable to have a service that returns configuration data so that other "stuff" in the system never has to change. That seems like a petty good design; but only if that service is really really reliable. To that end a database might not even be the best thing. Especially given that might mean DBAs additional approvals, yet another set of access credentials for the service to use, and all that enterprise-y stuff.
Certainly there has to be middle road. Why can't you have your service read the values for an XML/YAML/TML/INI/... file? That way at least you don't have to do a new build when things do have to change. Update the file, check it in, push it to prod...done!
Admin
Back in the days of FORTRAN, I used to have to edit a source code file every year to add the dates of our public holidays into a common data block, and then do a complete recompilation of the codebase. Whenever I suggested we put the values into a data file which could then be read by the various routines that used it without having to amend the code, it was "not worth the expense". I just waited till I had adequate autonomy over the code (and for the person making that decision to be shuffled sideways into a position where she could do least damage) and then just did it.
Admin
Ummm... did no one spot the indexing WTF here yet? O_o
Admin
I once had something almost this bad.
Back at previous employer (large bank - think stagecoach) in the brokerage division there was an app that calculated pay for a certain subset of brokers. As this was payroll it was date dependent. Pay cycles were every two weeks. Cutoff dates were available in 'other' systems. But not for this app. It maintained it's own dates table. When it was first written (2005 in VB6) it was two companies previous. When the app started it checked this table to determine if this was a payroll cycle. Didn't do anything with the date - just used as a 'check' to allow the app to run. Dates were hardcoded in the database (I always love date 'logic') in the format YYYY, MMM, DD. The original developer(s) (may the be cursed) included 10 years through Nov 2015 in the table. never added a note to this effect. Payroll started for Dec 2015. Errored on startup with an 'object reference' error
The management 'fix' was to create a SQL script to insert rows into the table for the next 25 years. So come late 2040 I expect some developer will get some strange error. I at least left documentation.
Admin
Back in the 90ies I stumbled upon a program which generated a report about the previous month. You just had to edit the source and tell it, what the previous month was. I added the needed calculation for those dates and an optional parameter for giving any other month, should you need to recreate old reports. Just three months later the saved maintenance had paid for the change.
Admin
Use the services database credentials to make direct DB updates!
Admin
If you leave out one character, why not three of them and a little swap? Initrode Comical
Admin
Unfortunately there are many use cases where data is important enough to require human intervention to do things to it, as opposed to having an automated facility.
Also unfortunate was the design of that particular process - they forgot the other part of the balance between security and usability (the usability part).
Admin
Maybe by then they'll move on to a newer system. Although, more likely they'll be using the same one
Admin
This is wrong on so many levels...
Since this REST call is insecure anyway, and Philip already had access to the source code, I would have added another POST REST method that takes a proper JSON request for the updates. That shouldn't take more than an hour, and every next time all you would need to is use cURL to send a POST request instead of a GET request.
Admin
Devops!
Admin
I made that change in our system. That's how I came to win a Mayan calendar stone as a "Golden Fleece" prize, for overdesign.
Admin
I don't think this is a service that returns SWIFT codes.
I think this is a service that updates the database, using the service credentials, because there was no other way:
DatastoreServiceFactory.getDatastoreService().put(entity);
Admin
The longer I look the worse it gets.
I can forgive hard coding for something that rarely changes, Inner Platform is bad too. But why in all of hell is it put in as a big long string and then split? And what is that return value!? Why is this not stored as some sort of dictionary/map?
Admin
Er. Um. Stagecoach is a bus company. (Bunch of wankers, too, but definitely not a bank.)
https://en.wikipedia.org/wiki/Stagecoach_Group
Addendum 2018-11-09 06:06: EDIT: Yes, I'm being deliberately obtuse. I'm like that sometimes.
Admin
"I would have added another POST REST method that takes a proper JSON request for the updates" – But then, you have a public service accepting arbitrary data to your SWIFT database. (There might be a problem.) As is, the worst case scenario may be you're running the update with the hard coded values again, causing essentially no harm. (Also, since you're just triggering a routine, I guess, GET is ok. This is not REST.)
Admin
25 years; see I just don't get management. I understand not taking the effort to design a "generic" fix that would work indefinitely. 25 years though seems like its just asking for trouble. It creates the possibility of running into the problem again where documentation or no the skills sets and the tools used to modify the software will be distant memories of the oldest members of the IT group.
Why not 100 years! A few extra kilobytes in database rows would virtual ensure that anyone still dependent on that system for day to day will be long retired most probably long dead; and any corporate interest in the historical data it might contain long past.
Admin
Remove the customers - then you have no problems.
Admin
Sometimes, things are just not worth fixing. Seriously, most of the systems I've worked on have had a lifespan of about 3-5 years; meaning that if you patch it in such a way that you don't need to do anything for another 5 years, chances are you won't have to do it again ever.
And, to the OP: if you have a chance to modify the service to insert new data, and you invoke it with curl, just create a new endpoint that accepts one row of data as parameters; now you have a UI (sort of) that you can add new data any time without needing to modify the code again. Easy Peasy.
Admin
So the code gets pushed to a machine by the build server. Developers have no access to that machine, the database is only accessible inside its private network. The endpoint does not need to be secured because the values are hardcoded. The only security issue here is a possible DOS, updating the db on each request. Good setup for a dev who needs some least effort quick fix. Badly written code though, splitting strings instead of just creating an object from the beginning..
Admin
You can't tell that from the information given. Many of the effective ways of securing this sort of thing wouldn't be seen on a per-method basis.
Admin
At one point I had occasion to add rows to a rather pointless table in an Access database: it had two columns, one with months in the format MM YYYY and one with the same month in format YYYY MM. Speculation was that this was a "pay me for maintenance" design by the external developer of the system, since this was in the password-protected back end that we didn't have access to; fortunately it had been discovered that we could get to it via the Linked Tables feature. Sales budgets couldn't be entered for any month that didn't have an entry in this table.
I had joined the company as part of the migration effort to replace the whole system, so we didn't have to put up with this for too long.
Admin
i == 0 i == 0 i++ == 1 i == 1 i++ == 2 i == 2 i++ == 3