Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

The Gripper: Sep 14, 2004; i am winner

ultramiraculous posted:

Oh, man. I'm now imagining the new guy coming and rewriting half the code base on Master and committing it as "asdfsababuttes".

We had a new guy quit after he rewrote a huge portion of a system (unsolicited) with just one commit message: "updated program_name". No other commit history whatsoever.

We couldn't/wouldn't merge and told him he'd have to go back and separate changes and instead he put in his resignation with a snide "good luck with your old code heh" and a threat of lawsuit if we used any of his code in the end.

If I can find the resignation on file I'll redact and scan it because it's pretty much a perfect storm of misguided butthurt.

e; it was basically "I did all the work in my own branch I don't need individual commits and you're dumb and wrong if you disagree!"

# ? Jan 4, 2013 07:33

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 06:19

UraniumAnchor: May 21, 2006; Not a walrus.

The Gripper posted:

a threat of lawsuit if we used any of his code in the end.

I can't even begin to think why you would say something like this as a regular employee.

# ? Jan 4, 2013 09:51

b0lt: Apr 29, 2005

UxP posted:

Both of those are equal horrors.

Any code I come across with the hint of print or echo horseshit debug statements is code I don't want to touch. Learn to use a goddamned debugger. If all you use it for is to inspect a variable, you're 90% better than any asshat that doesn't know how to run one.

code:

//asm("int $0x3");

# ? Jan 4, 2013 10:07

dexter: Jun 24, 2003

Steampunk Hitler posted:

Global variables are great. Hope you didn't want to run a second copy in the same process.

If it's the same process, shouldn't it share the same configuration variables? We don't use environment variables for configuration (outside of random hack day projects that get pushed to Heroku) but it's an idea we've thrown around to simplify the deployment of new applications without pulling operations in. Right now repositories have development-mode only credentials that are overwritten by our deployment processes with real credentials. Can you expand on why environment variables are a horror?

# ? Jan 4, 2013 11:11

The Gripper: Sep 14, 2004; i am winner

UraniumAnchor posted:

I can't even begin to think why you would say something like this as a regular employee.

His reasoning was that because he'd done the work on his own time it was his and his alone, despite the fact that the work was done on a company-internal codebase and submitted by himself as work done by a full-time employee.

The "I coded this with no outside help!" argument, I guess.

# ? Jan 4, 2013 11:47

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

dexter posted:

If it's the same process, shouldn't it share the same configuration variables? We don't use environment variables for configuration (outside of random hack day projects that get pushed to Heroku) but it's an idea we've thrown around to simplify the deployment of new applications without pulling operations in. Right now repositories have development-mode only credentials that are overwritten by our deployment processes with real credentials. Can you expand on why environment variables are a horror?

The expanded reason is your application shouldn't rely on environment variables and instead your startup script (or wsgi file, or whatever) should accept those environment variables and feed them into a sane configuration method.

A contrived/simple example would be a flask app that just simply serves a directory and takes the directory to serve as a parameter. If you have in the app the concept of loading config from an environment variable then if you want to serve 2 directories you need to either a) Modify the app to handle a list of directories, b) run 2 separate processes one configured for dir 1, one configured for dir 2, or c) use Application dispatching to run multiple instances of the same flask app in the same process with different configurations. (http://flask.pocoo.org/docs/patterns/appdispatch/). It might not even be 2 instances of the same app but just 2 different apps you want to live in the same process and both have a hardcoded reference to "DATABASE_URL".

Another example of where you'll want to possibly run multiple configurations of the same app in the same process is with unit testing. Anyones whose used Django can attest to how much of a pain in the rear end it is to handle testing different configurations when unit testing a library. The bulk of this problem comes down to the massive amount of global state in Django, starting with DJANGO_SETTINGS_MODULE.

The *right* way to do configuration from an environment variable is to do something like:

Python code:

    import os
    import myapp

    database_url = os.environ.get("DATABASE_URL")

    app = myapp.create_app(config={"DATABASE_URL": database_url})
    app.run()

and then down the road when you add in another app that also wants a DATABASE_URL configured it becomes

Python code:

import os

from werkzeug.serving import run_simple
from werkzeug.wsgi import DispatcherMiddleware

import myapp
import otherapp

myapp_config = {
    "DATABASE_URL": os.environ.get("DATABASE_URL_MYAPP"),
}

otherapp_config = {
    "DATABASE_URL": os.environ.get("DATABASE_URL_OTHERAPP"),
}


application = DispatcherMiddleware(myapp.create_app(config=myapp_config), {
    "/otherapp": otherapp.create_app(config=otherapp_config),
})

run_simple('localhost', 5000, application, use_reloader=True)

The key being that your process global environment variable style configuration is being "injected" into your application instance, the application instance isn't reaching out looking at a process global. Doing that you've gained all the good parts of configuration from the environment while retaining all the benefits of not having configuration being a process global.

Comrade Gritty fucked around with this message at 13:50 on Jan 4, 2013

# ? Jan 4, 2013 13:42

Hughlander: May 11, 2005

Thermopyle posted:

Github works like this if you use their issue tracker. You can have a commit message with "Closes #128" in it and it automatically links to the issue, closes it, and links from the issue to the commit.

That got glossed by in the pile on of other poo poo, but to me that's seriously a WTF. Does it do that only in things that are pushed to master? Or does it work in other branches? Bugs are closed on pushing a commit as opposed to acceptance by QA or production? WTF! (Which leads me again to think we should have a process horror thread.)

# ? Jan 4, 2013 15:44

Slash: Apr 7, 2011

Hughlander posted:

That got glossed by in the pile on of other poo poo, but to me that's seriously a WTF. Does it do that only in things that are pushed to master? Or does it work in other branches? Bugs are closed on pushing a commit as opposed to acceptance by QA or production? WTF! (Which leads me again to think we should have a process horror thread.)

It's only if you use the keywords 'closes #[issue no]'. If you don't want to close the ticket, then don't include those words in your commit message.

# ? Jan 4, 2013 15:47

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Hughlander posted:

That got glossed by in the pile on of other poo poo, but to me that's seriously a WTF. Does it do that only in things that are pushed to master? Or does it work in other branches? Bugs are closed on pushing a commit as opposed to acceptance by QA or production? WTF! (Which leads me again to think we should have a process horror thread.)

It depends on how you're handling your work items, really. I've always closed dev tasks when development was done. The user story, though, stays open until it's passed UAT and everything is merged back into mainline.

# ? Jan 4, 2013 15:56

armorer: Aug 6, 2012; I like metal.

Github's issue tracker is a piece of worthless garbage compared to any real bug tracking system. I have to use it daily for work, and I would rather install bugzilla, trac, or please god yes JIRA on my own workstation and maintain it myself than use github's system. Unfortunately that is not an option because I am a consultant and the clients want it this way. That said, it kind of lets you track stuff, which is better than nothing.

My main issue with it is that you sort of have to invent your own issue lifecycle on top of it using labels in order for it to work. That is prone to user errors, because there isn't any requirement that labels ever be used or updated. Any sort of issue metadata that you want to track has to be manually typed into each issue, which makes it dubious at best to search through. If you want to know what version an issue was found in, which it affects, and which versions the fix is included in, good luck to you. If you only ever need to know if a bug has been fixed, then it is probably awesome. You also can't attach anything to issues, so useful log snippets have to be copied into comments, and screenshots have to be uploaded to another server and hyperlinked to.

I have to maintain several production versions of our application, and it gets messy to keep track of. I have taken to creating duplicate issues in other milestones that link back to the "fix" milestone in order to accurately represent what changes are in what releases. Otherwise, if I merge up fixes from one production branch into a later one, there is no record that those changes were included in the github milestone.

As far as issue lifecycle, we use a series of labels which align with our process to track it, and only close the issues once a release passes UAT and is installed to production. This is partly because github milestones that contain only closed issues are moved to a different "tab" in the github UI. Closing issues before the milestone is in production results in that milestone "falling off" of people's main view into the issues, which is rather undesirable.

# ? Jan 4, 2013 16:00

Bunny Cuddlin: Dec 12, 2004

A little while ago I was looking for a distributed issue tracker (that works like git, but for issues) and I was surprised that the only projects that exist are abandoned and in various states of decay. It seems like something that would be useful, and it looks like 3 or 4 projects started up at the same time, but then everyone stopped caring about them for some reason.

# ? Jan 4, 2013 16:02

Posting Principle: Dec 10, 2011; by Ralp

My old job used a combo of HPQC and email chains to track bugs :suicide:

# ? Jan 4, 2013 16:04

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

armorer posted:

As far as issue lifecycle, we use a series of labels which align with our process to track it, and only close the issues once a release passes UAT and is installed to production. This is partly because github milestones that contain only closed issues are moved to a different "tab" in the github UI. Closing issues before the milestone is in production results in that milestone "falling off" of people's main view into the issues, which is rather undesirable.

We have a kanban board that uses github issue labels as the backing store, and it seems to work pretty well. If github issues isn't working for you, you should probably move off of it to something that does, because they're probably not going to change much.

# ? Jan 4, 2013 16:56

armorer: Aug 6, 2012; I like metal.

I am not saying it doesn't work - it does. In fact I just described at a high level how we use it to solve our problems. It just doesn't work even remotely as well as other tools I have used in the past. Unfortunately this project is such that I don't have the freedom to use something else. I have tried, and the answer was a pretty solid "no". Also I have no expectation that the github "issues" feature is going to change much. It isn't their main business, and any company that has more complex needs will probably use one of the existing issue trackers out there instead. I was mostly pointing out that it leaves quite a bit to be desired if you have more complex needs.

# ? Jan 4, 2013 17:10

SavageMessiah: Jan 28, 2009; Emotionally drained and spookified; Toilet Rascal

armorer posted:

Github's issue tracker is a piece of worthless garbage compared to any real bug tracking system. I have to use it daily for work, and I would rather install bugzilla, trac, or please god yes JIRA on my own workstation and maintain it myself than use github's system. Unfortunately that is not an option because I am a consultant and the clients want it this way. That said, it kind of lets you track stuff, which is better than nothing.

My main issue with it is that you sort of have to invent your own issue lifecycle on top of it using labels in order for it to work. That is prone to user errors, because there isn't any requirement that labels ever be used or updated. Any sort of issue metadata that you want to track has to be manually typed into each issue, which makes it dubious at best to search through. If you want to know what version an issue was found in, which it affects, and which versions the fix is included in, good luck to you. If you only ever need to know if a bug has been fixed, then it is probably awesome. You also can't attach anything to issues, so useful log snippets have to be copied into comments, and screenshots have to be uploaded to another server and hyperlinked to.

I have to maintain several production versions of our application, and it gets messy to keep track of. I have taken to creating duplicate issues in other milestones that link back to the "fix" milestone in order to accurately represent what changes are in what releases. Otherwise, if I merge up fixes from one production branch into a later one, there is no record that those changes were included in the github milestone.

As far as issue lifecycle, we use a series of labels which align with our process to track it, and only close the issues once a release passes UAT and is installed to production. This is partly because github milestones that contain only closed issues are moved to a different "tab" in the github UI. Closing issues before the milestone is in production results in that milestone "falling off" of people's main view into the issues, which is rather undesirable.

I'm surprised it's so bad - bitbucket's issue tracker seems quite a bit better, though still probably short of a good standalone tracker. It has basic built in workflow stuff, you can attach files, and I see in the settings that you can add versions, milestones, and components, though I've not used them.

On the other hand bitbucket seems to be a fair bit better than github in other ways - unlimited private repos, hg and git, etc.

# ? Jan 4, 2013 17:11

Deus Rex: Mar 5, 2005

SavageMessiah posted:

I'm surprised it's so bad - bitbucket's issue tracker seems quite a bit better, though still probably short of a good standalone tracker. It has basic built in workflow stuff, you can attach files, and I see in the settings that you can add versions, milestones, and components, though I've not used them.

On the other hand bitbucket seems to be a fair bit better than github in other ways - unlimited private repos, hg and git, etc.

bitbucket's issue tracker probably has these jira-like features because of Atlassian.

# ? Jan 4, 2013 17:33

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Github's issue tracker is far from the worst I've used. It's actually pretty polished and does everything it tries to do well; it's just seriously lacking in features. It's a pretty good showcase for the up and downsides of dogfood-driven development. How much you like github issues is probably pretty directly correlated to how similar your project's workflow is to Github's.

# ? Jan 4, 2013 17:36

Doctor w-rw-rw-: Jun 24, 2008

Steampunk Hitler posted:

The *right* way to do configuration from an environment variable is to do something like:
Python code:
    import os
    import myapp

    database_url = os.environ.get("DATABASE_URL")

    app = myapp.create_app(config={"DATABASE_URL": database_url})
    app.run()
and then down the road when you add in another app that also wants a DATABASE_URL configured it becomes
Python code:
import os

from werkzeug.serving import run_simple
from werkzeug.wsgi import DispatcherMiddleware

import myapp
import otherapp

myapp_config = {
    "DATABASE_URL": os.environ.get("DATABASE_URL_MYAPP"),
}

otherapp_config = {
    "DATABASE_URL": os.environ.get("DATABASE_URL_OTHERAPP"),
}


application = DispatcherMiddleware(myapp.create_app(config=myapp_config), {
    "/otherapp": otherapp.create_app(config=otherapp_config),
})

run_simple('localhost', 5000, application, use_reloader=True)
The key being that your process global environment variable style configuration is being "injected" into your application instance, the application instance isn't reaching out looking at a process global. Doing that you've gained all the good parts of configuration from the environment while retaining all the benefits of not having configuration being a process global.

Sorry, this just sounds kind of nuts. Why not just make a config.py and do "import config", add it to .gitignore, then copy it sans credentials as config.py.example and add that to source control?

The possibility of very heterogenous configurations because of configurable environment variables strikes me as a bad idea - not the idea of using an environment variable itself. With a file, you control how many configurations you have deployed, and certainly, if you like, you can even use environment variables to select what config file is being imported.

EDIT: On an unrelated note, Android finally broke me. The collective horror from its awfulness finally burnt me out completely, and though I still love my employer, I'm on a leave of absence to recover. It got to the point where I was unable to alt-tab into Eclipse without panicking.

This is the app that drove me insane: Crunchyroll

Doctor w-rw-rw- fucked around with this message at 18:09 on Jan 4, 2013

# ? Jan 4, 2013 18:02

Freakus: Oct 21, 2000

Using environment variables doesn't rise to the level of "horror" in my book. I consider running 2 different apps under the same user a bigger problem because any security holes in one app will likely compromise the other app.

# ? Jan 4, 2013 19:40

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Doctor w-rw-rw- posted:

EDIT: On an unrelated note, Android finally broke me. The collective horror from its awfulness finally burnt me out completely, and though I still love my employer, I'm on a leave of absence to recover. It got to the point where I was unable to alt-tab into Eclipse without panicking.

This is the app that drove me insane: Crunchyroll

Ugh...feel free to rant, I want to hear some horror. We're about to embark on an Android app and I'm nervous/want to hear some specific gripes. I haven't done any Android work since I bought someone's G1 to dick around with, and it was awful.

Edit: Found your Android thread rants. :sigh:

ultramiraculous fucked around with this message at 21:16 on Jan 4, 2013

# ? Jan 4, 2013 19:41

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Doctor w-rw-rw- posted:

EDIT: On an unrelated note, Android finally broke me. The collective horror from its awfulness finally burnt me out completely, and though I still love my employer, I'm on a leave of absence to recover. It got to the point where I was unable to alt-tab into Eclipse without panicking.

This is the app that drove me insane: Crunchyroll

Your ranting in the Android thread made me understand Netflix's decision to roll out based on a somewhat strict hardware compatibility list, but somehow I didn't think you were basically in the same business. I bet the anime-obsessed user base is even more annoying to deal with than the "I was hoping to catch up on the last season of <generic reality show> during a meeting" user base, too :\

# ? Jan 4, 2013 20:24

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Doctor w-rw-rw- posted:

Sorry, this just sounds kind of nuts. Why not just make a config.py and do "import config", add it to .gitignore, then copy it sans credentials as config.py.example and add that to source control?

Because that's a pain in the rear end to set up every time you want to run the app on a new machine. With an environment variable, I can set sane defaults, and allow somebody to override them with the config file of their choice, an execution manager that loads values from the network, or a bunch of other techniques that don't involve writing configuration file templates.

# ? Jan 4, 2013 20:31

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Cocoa Crispies posted:

Because that's a pain in the rear end to set up every time you want to run the app on a new machine. With an environment variable, I can set sane defaults, and allow somebody to override them with the config file of their choice, an execution manager that loads values from the network, or a bunch of other techniques that don't involve writing configuration file templates.

But the config.py.example file in his example is a set of sane defaults that other people can override if they want however they want, so how is it worse? Having to synchronize and track environment variables sounds more annoying and error-prone to me.

# ? Jan 4, 2013 21:00

dexter: Jun 24, 2003

Steampunk Hitler posted:

and then down the road when you add in another app that also wants a DATABASE_URL configured it becomes

Python code:

import os

from werkzeug.serving import run_simple
from werkzeug.wsgi import DispatcherMiddleware

import myapp
import otherapp

myapp_config = {
    "DATABASE_URL": os.environ.get("DATABASE_URL_MYAPP"),
}

otherapp_config = {
    "DATABASE_URL": os.environ.get("DATABASE_URL_OTHERAPP"),
}


application = DispatcherMiddleware(myapp.create_app(config=myapp_config), {
    "/otherapp": otherapp.create_app(config=otherapp_config),
})

run_simple('localhost', 5000, application, use_reloader=True)

If it needs to connect to another database then it probably shouldn't run in the same process as this application. I think it's better to use a smart HTTP routing layer to handle dispatching requests to disparate applications instead of mounting them within a single application.

Cocoa Crispies posted:

Because that's a pain in the rear end to set up every time you want to run the app on a new machine. With an environment variable, I can set sane defaults, and allow somebody to override them with the config file of their choice, an execution manager that loads values from the network, or a bunch of other techniques that don't involve writing configuration file templates.

This can be greatly simplified by a good deployment/configuration management system to automate all of it.

# ? Jan 4, 2013 21:02

Doctor w-rw-rw-: Jun 24, 2008

Munkeymon posted:

Your ranting in the Android thread made me understand Netflix's decision to roll out based on a somewhat strict hardware compatibility list, but somehow I didn't think you were basically in the same business. I bet the anime-obsessed user base is even more annoying to deal with than the "I was hoping to catch up on the last season of <generic reality show> during a meeting" user base, too :\

Oh, fandom is often times far more than just spergy (though it should be emphasized that this is a very miniscule, albeit very visible, subset of fans). The things I've seen the stranger ones do, man...but I digress. This thread is for coding horrors.

EDIT: So as to keep this post topical:
Video playing on Android is pretty much uniformly awful. The VideoView is a hacked-up piece of glue between a media player and a video surface that suffers greatly from legacy. It has problems pausing and resuming its state, which makes things difficult when you want to push another screen in front of it. You might think you could fix this by putting it in a fragment, but this doesn't work too well, either - if you use a FragmentPagerAdapter or FragmentStatePagerAdapter, neither really does a completely adequate job of saving the state if you have greater than two screens, not to mention it's literally impossible to disable paging on a ViewPager, even temporarily (the best you can do is disable touch-scroll gestures, but d-pads will skip that. If you think you can use the fragment backstack, think again - any kind of configuration change will result in the destruction and recreation of the Activity. Here's the thing, though - it'll restore the state of the fragment that was showing along with its state, but it WON'T restore the state of any of the fragments on the backstack.

:argh:

Who builds a stack abstraction to manage the state of the application then FORGETS TO SAVE THE STATE? The Android team does.

Yet another example of Android loving up mutable state. It's why rather than using onCreate to set variables, I would always just stuff them in the Intent and use a helper class to extract variables in a type-safe manner, i.e. Extras.get(bundle, Extras.SOMETHING, FooPojo.class) or Extras.getString(bundle, Extras.SOMETHING). Not only did this turn out to be more concise, but combining this with Guava, I had this return an Optional<FooPojo> or Optional<String>, respectively, and not worry at all about any sort of nullity problems or thrown exceptions on account of not being able to retrieve any values from the Intent or Bundle.

Doctor w-rw-rw- fucked around with this message at 21:46 on Jan 4, 2013

# ? Jan 4, 2013 21:36

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

dexter posted:

This can be greatly simplified by a good deployment/configuration management system to automate all of it.

Yes.

Locally, I use rbenv-vars to manage environment variables; in ~/Documents and /Volumes/clientproject I have a .rbenv-vars file that sets the RIAK_BIN_DIR for my machine, and it propagates down to projects in those directories.

In staging and production we use chef to manage environment variables that it jams into the appropriate init scripts.

# ? Jan 4, 2013 22:27

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

dexter posted:

If it needs to connect to another database then it probably shouldn't run in the same process as this application. I think it's better to use a smart HTTP routing layer to handle dispatching requests to disparate applications instead of mounting them within a single application.

The database url was just an example. splitting it into separate processes can make sense. It can also make sense to keep them in the same one. Hardcoding environment variables means you're forced to make them separate processes. Even if you think that there is never a reason to have the same app in the same process there's still the matter of testing and when you use process globals that makes running tests with different configurations involve lots of monkey patching instead of simply being to create another instance of your app with different configuration.

Maybe a better real world example would be the boto library which will (optionally) pull the AWS credentials from an environment variable. This makes it easy to mistakenly use the wrong credentials in the wrong place. Forget to pass in the configuration to your second instance of boto (or stand up a new instance and forget to include the configuration for the second AWS account and boto automatically grabs your config for the primary account out of the environment variables). boto mitigates the inability to connect to a second account by allowing you to pass in the configuration and not pull it from environment variables but the behavior still has potential to turn a bug that would be easily caught and fairly "harmless" (e.g. it would exception because of missing creds) into potentially a very bad bug that has no immediately obvious consequences.

# ? Jan 4, 2013 23:29

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

Doctor w-rw-rw- posted:

Sorry, this just sounds kind of nuts. Why not just make a config.py and do "import config", add it to .gitignore, then copy it sans credentials as config.py.example and add that to source control?

The possibility of very heterogenous configurations because of configurable environment variables strikes me as a bad idea - not the idea of using an environment variable itself. With a file, you control how many configurations you have deployed, and certainly, if you like, you can even use environment variables to select what config file is being imported.

A hardcoded or environment variable driven configuration file has all the same problems. It's a process global configuration source that makes it difficult or hard to run multiple instances of your thing in one process, and to test varying configurations without needing to resort to hacky monkeypatching.

# ? Jan 4, 2013 23:31

Doctor w-rw-rw-: Jun 24, 2008

Steampunk Hitler posted:

A hardcoded or environment variable driven configuration file has all the same problems. It's a process global configuration source that makes it difficult or hard to run multiple instances of your thing in one process, and to test varying configurations without needing to resort to hacky monkeypatching.

What solution would you advocate, though? I think that as far as transparency and refactor-ability go, having a hardcoded file that is the single source of truth beats pulling variables in from the environment. Fully functional configuration management IMO gets in the way at small scale (well, for me at least), however essential it is at large scale.

# ? Jan 4, 2013 23:53

dexter: Jun 24, 2003

Steampunk Hitler posted:

The database url was just an example. splitting it into separate processes can make sense. It can also make sense to keep them in the same one. Hardcoding environment variables means you're forced to make them separate processes. Even if you think that there is never a reason to have the same app in the same process there's still the matter of testing and when you use process globals that makes running tests with different configurations involve lots of monkey patching instead of simply being to create another instance of your app with different configuration.

What sort of configuration changes are you making between test runs? Shouldn't those changes be managed within the individual unit or functional test groups?

Steampunk Hitler posted:

Maybe a better real world example would be the boto library which will (optionally) pull the AWS credentials from an environment variable. This makes it easy to mistakenly use the wrong credentials in the wrong place. Forget to pass in the configuration to your second instance of boto (or stand up a new instance and forget to include the configuration for the second AWS account and boto automatically grabs your config for the primary account out of the environment variables). boto mitigates the inability to connect to a second account by allowing you to pass in the configuration and not pull it from environment variables but the behavior still has potential to turn a bug that would be easily caught and fairly "harmless" (e.g. it would exception because of missing creds) into potentially a very bad bug that has no immediately obvious consequences.

I don't work on multi-tenant applications currently but at my last employer we baked the logic of switching credentials into the application itself; we didn't run individual instances for each client as it's a waste of resources and complicates deploys for very little gain. This meant nothing tenant-specific was allowed to be configured at run-time, only on a per-request basis ensuring that configuration state was consistent for exactly the reason you outlined above.

Doctor w-rw-rw- posted:

What solution would you advocate, though? I think that as far as transparency and refactor-ability go, having a hardcoded file that is the single source of truth beats pulling variables in from the environment. Fully functional configuration management IMO gets in the way at small scale (well, for me at least), however essential it is at large scale.

We start by including example configuration files (database.yml, etc) in each repository (so you can just clone/run the test suite without actually setting the environment up) but our configuration management system writes the real files that are used in all environments. They get written to the VMs prior to the code base ever being deployed and are easily inspected as they're symlinked in place of the example files.

Manual configuration of development, staging, test and production environments isn't acceptable anywhere I've worked. Automating it for one environment means you're probably 90% of the way there for the others.

It seems like a hassle with small projects but you'll be punching yourself (and team) in the face if it's not implemented early.

dexter fucked around with this message at 02:26 on Jan 5, 2013

# ? Jan 5, 2013 02:23

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

Doctor w-rw-rw- posted:

What solution would you advocate, though? I think that as far as transparency and refactor-ability go, having a hardcoded file that is the single source of truth beats pulling variables in from the environment. Fully functional configuration management IMO gets in the way at small scale (well, for me at least), however essential it is at large scale.

App class that holds configuration as an instance member. You can configure that class in the script_you_use_to_actually_start_your_app (in my example it was a simple python script that just ran app.run() from Flask). Your configuration can come from a file, or environment variables or what not but when you instiate your application/library/whatever you process that file and then pass the configuration into your app instead of your app itself looking for a file, environment variable, etc.

Python code:

class GoodApp(object):
    def __init__(self, config):
        self.config = config

    def do_something(self):
        if self.config.DEBUG:
            print "Running my do_something method"

import config

class BadApp(object):

    def do_something(self):
        if config.DEBUG:
            print "Running my do_something method"

if __name__ == "__main__":
    import config
    import config2
    app1 = GoodApp(config=config)
    app2 = GoodApp(config=config2)
    app3 = BadApp()

The actual source of configuration isn't the bad part, but how your application gets it's configuration from that source is. If your app reaches out and tries to use a python module (ala Django) or the environment (ala Boto), it makes it more difficult to actually use the app in the same process for whatever reason (testing, hosting, whatever).

Comrade Gritty fucked around with this message at 03:50 on Jan 5, 2013

# ? Jan 5, 2013 03:48

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

dexter posted:

What sort of configuration changes are you making between test runs? Shouldn't those changes be managed within the individual unit or functional test groups?

Yes, but if your application assumes it's configuration is coming from the environment variable, or a particular file on the system then you need to patch the global state in your unit test to test those changes, instead of having your unit test just instantiate a new copy of your app configured a particular way.

# ? Jan 5, 2013 03:53

Sereri: Sep 30, 2008; awwwrigami

Munkeymon posted:

I bet the anime-obsessed user base is even more annoying to deal with than the "I was hoping to catch up on the last season of <generic reality show> during a meeting" user base, too :\

From the market:

A Google User posted:

Need to implement 720 and 1080 for app
Awesome source for watching my animes and korean dramas but granted i know i pay for 1080p on the website, why is it not possible to stream 1080 on my device. Youtube and other sources can stream 1080p why not tablets and HD capable devices. Asus TF700t tablet and Droid Razr Maxx

2 stars

# ? Jan 5, 2013 04:06

Coffee Mugshot: Jun 26, 2010; by Lowtax

Ephphatha posted:

Perl code:

$divideby = 1;
$count = 1;
foreach (my $entry in $options) {
    $html .= "<td>a checkbox and label using values from $entry</td>";
    if ($count / $divideby == 4) {
        $html .= "</tr>\n<tr>";
        $divideby++;
    }
    $count++;
}

Sorry, this is from last page, but this stands out to me as a serious coding horror in PHP. I really don't understand this, but it really seems like PHP devs are extremely adverse to using templating engines and instead there ends up being disgusting html string building and printing. I used to do it, too, but I even see some bigger projects straight up echo out html. Is there something inherently flawed about templating engines that I'm not aware of?

# ? Jan 5, 2013 20:52

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Rainbow Pony Deluxe posted:

Sorry, this is from last page, but this stands out to me as a serious coding horror in PHP. I really don't understand this, but it really seems like PHP devs are extremely adverse to using templating engines and instead there ends up being disgusting html string building and printing. I used to do it, too, but I even see some bigger projects straight up echo out html. Is there something inherently flawed about templating engines that I'm not aware of?

It's not PHP specific, it's "bad developer" specific. I've seen the same thing in ASP .NET and classic ASP.

# ? Jan 5, 2013 20:56

nielsm: Jun 1, 2009

Rainbow Pony Deluxe posted:

Sorry, this is from last page, but this stands out to me as a serious coding horror in PHP. I really don't understand this, but it really seems like PHP devs are extremely adverse to using templating engines

Odd, seeing that PHP itself is a templating engine, that has massively grown out of its original purpose.

(By the way that code you quoted is not PHP, it's Perl.)

# ? Jan 5, 2013 20:57

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Some people just take comfort in developing the hard way that they know rather than the easy way they could learn. I also have had to repeatedly hassle a developer to move tags out of his code sections.

# ? Jan 5, 2013 23:31

The Gripper: Sep 14, 2004; i am winner

Ithaqua posted:

It's not PHP specific, it's "bad developer" specific. I've seen the same thing in ASP .NET and classic ASP.

Especially true since the quoted code is actually Perl.

# ? Jan 6, 2013 02:20

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Tomayto, tomahto.

# ? Jan 6, 2013 02:25

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 06:19

pigdog: Apr 23, 2004; by Smythe

edit: nevermind, i remembered wrong

pigdog fucked around with this message at 03:20 on Jan 6, 2013

# ? Jan 6, 2013 03:17

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »