I just don't get choosing something that makes you work significantly harder at just getting it right ... PHP specifically seems to take that making it harder to just get it right ...
I've never really run into any trouble getting non-PHP environments up and working.
It seemed like you were talking PHP to me and implying it with the last one with the counter-statement. If not then nevermind.
Ah, sorry. I should have been more clear. That second line was in response to @bowen having a hard time initially getting Ruby setup. Btw, I'm in no way saying that shouldn't have been the case since it was easy for me, depending on exact needs and whatnot, it certainly could have been a hassle... and I suspect it was being setup on a Mac, whereas I've always done it on Linux.
Unrelated, if you are having shoe smell issues, make sure you are never wearing shoes the day after you just wore them at the very least. You need to let them breathe and dry at least a day, which means you need to rotate at the minimum two pairs of shoes and preferably three.
I got stuck in using the same shoes over and over due to colour choice at one point and it got real bad. So I keep a couple brown and a couple black shoes available now.
I dream of the day that "more shoes" is at the top of my spending priorities. It will be a good day indeed... and less stinky.
Also, congrats @urahonky and @Gilbert0 on the babies! Mine is just over 5 months old. Get in some quality time with your hobbies now because you won't for awhile after the baby, but it's worth it.
Also the power just went out and we're on backup.... Oddly enough the Developers area is completely lightless, but the management side is perfectly fine.
That looks really interesting. The highest level I ever got for that stuff was making CSS sprite sheets.
0
mightyjongyoSour CrrmEast Bay, CaliforniaRegistered Userregular
Fuck backwards compatibility. Refactoring feels so futile when I have to keep the same struct and fields and account for their state because we need to maintain backwards compat. I mean what's the point if I have to keep everything in the first place?
Make prettier code, basically, and organize it better.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
mightyjongyoSour CrrmEast Bay, CaliforniaRegistered Userregular
Well...Hm. I guess that's what a refactor is, isn't it...
Maybe it's more of a reimplementation then - I wanted to clean up one of our external-facing structs because it had a lot of fields that will no longer be necessary with the new implementation, and now I'm forced to keep the old fields, which really just mucks it up even more.
I mean, when are you allowed to just stop and say, look, it's not backwards compatible anymore starting from Version X.
That's what I would do. I'm not gonna lie, I've made up excuses that we can't be backwards compatible because of (made up reason) because sometimes fuck your business goals, it needs to be done right.
People get over it after like a week.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Well...Hm. I guess that's what a refactor is, isn't it...
Maybe it's more of a reimplementation then - I wanted to clean up one of our external-facing structs because it had a lot of fields that will no longer be necessary with the new implementation, and now I'm forced to keep the old fields, which really just mucks it up even more.
I mean, when are you allowed to just stop and say, look, it's not backwards compatible anymore starting from Version X.
Part of your reimplementation should handle backwards compatibility. You are taking the easy way out if you don't think about these issues when you have the chance. If you offer backwards API compatibility you should also have infrastructure to mark items as deprecated. If you offer ABI compatibility, well good luck and move to internal pointers + methods / functions.
If you have inheritance / templates you can solve the issue by having a legacy child class that conforms to the old struct memory layout. With pure structs I expect some nice macros will allow you to conditional expose the old struct.
Well...Hm. I guess that's what a refactor is, isn't it...
Maybe it's more of a reimplementation then - I wanted to clean up one of our external-facing structs because it had a lot of fields that will no longer be necessary with the new implementation, and now I'm forced to keep the old fields, which really just mucks it up even more.
I mean, when are you allowed to just stop and say, look, it's not backwards compatible anymore starting from Version X.
Another alternative is to bring in the new interface, and reimplement the old interface in terms of the new interface.
Just mark the old fields "deprecated", and "will be removed in x major versions".
Might work depending on how your relationship with your clients are
Edit: Dammit Ethea! Your timestamp is earlier this time!
Just gonna point out that changing your API / interface isn't refactoring alone. Refactoring would be activities that let me clean up my own mess without others dependent on me giving a shit, which means I can't be changing the API side of things.
If you have field changes in your API that is a versioning issue. Basically you should always have a version number attached to your APIs, the clients send the version number they are communicating with, you handle it or not based on your level of support. You have min_version and max_version defined, you only accept clients in that range and give a version mismatch failure (that all versions will know how to handle). Then you can at some point in the future go "fuck everyone still using pre 1.5.2, you have been given notice a year out that we were ending support" and then you publish with a cleaned up and refactored API and bump min_version to 1.5.2 and voila, those not upgrading are now refused service. You no longer need to support them and the reason why things are broken is clearly defined and communicated.
Gotta keep them on their toes. Redesigning that shit erryday.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
mightyjongyoSour CrrmEast Bay, CaliforniaRegistered Userregular
Luckily it's not a product with an exposed API, so it's mostly internal. As far as I know the main sticking point is that we have a lot of scripts and tests that revolve around these fields, so we need to keep them valid until the scripts are updated.
I mean I would love to tell the testers to deal with it buuut then schedule slip blah blah management. The problem with that is that there's really not much forcing them to adapt - they could use these fields for another 5 years and nothing would break.
Went and updated the management accounts, and taking this opportunity to migrate to the NextGen servers, which are double RAM and better hardware for the same price.
yeah I'm running at the 2048 level (was 1024) so I might to do that if I can't think of anything additionally useful to put on it, since I have something like 500MB completely free (not even being used by cache) after a few days
although also, when I first set up this VM, I was running both postgres and mysql, as well as a lot more php stuff, and I've consolidated everything into postgres and rewrote some of the php stuff into the python webapp, so overall memory usage had gone down anyway
End on
I wish that someway, somehow, that I could save every one of us
edit: same processor even (and that's not the E5-2670 they were talking about the new hardware running, but I don't know if they have any of those running just yet)
End on
I wish that someway, somehow, that I could save every one of us
still, E5-2630L is like 3 years newer than the processor I was running on before (which I don't remember the name of and obviously can no longer check)
I wish that someway, somehow, that I could save every one of us
Posts
?
I dream of the day that "more shoes" is at the top of my spending priorities. It will be a good day indeed... and less stinky.
Also, congrats @urahonky and @Gilbert0 on the babies! Mine is just over 5 months old. Get in some quality time with your hobbies now because you won't for awhile after the baby, but it's worth it.
That's awesome but it still looks way too clean, properly aligned, etc.
See? Content is king!
Maybe it's more of a reimplementation then - I wanted to clean up one of our external-facing structs because it had a lot of fields that will no longer be necessary with the new implementation, and now I'm forced to keep the old fields, which really just mucks it up even more.
I mean, when are you allowed to just stop and say, look, it's not backwards compatible anymore starting from Version X.
People get over it after like a week.
Part of your reimplementation should handle backwards compatibility. You are taking the easy way out if you don't think about these issues when you have the chance. If you offer backwards API compatibility you should also have infrastructure to mark items as deprecated. If you offer ABI compatibility, well good luck and move to internal pointers + methods / functions.
If you have inheritance / templates you can solve the issue by having a legacy child class that conforms to the old struct memory layout. With pure structs I expect some nice macros will allow you to conditional expose the old struct.
Another alternative is to bring in the new interface, and reimplement the old interface in terms of the new interface.
Just mark the old fields "deprecated", and "will be removed in x major versions".
Might work depending on how your relationship with your clients are
Edit: Dammit Ethea! Your timestamp is earlier this time!
It works.
If you have field changes in your API that is a versioning issue. Basically you should always have a version number attached to your APIs, the clients send the version number they are communicating with, you handle it or not based on your level of support. You have min_version and max_version defined, you only accept clients in that range and give a version mismatch failure (that all versions will know how to handle). Then you can at some point in the future go "fuck everyone still using pre 1.5.2, you have been given notice a year out that we were ending support" and then you publish with a cleaned up and refactored API and bump min_version to 1.5.2 and voila, those not upgrading are now refused service. You no longer need to support them and the reason why things are broken is clearly defined and communicated.
I mean I would love to tell the testers to deal with it buuut then schedule slip blah blah management. The problem with that is that there's really not much forcing them to adapt - they could use these fields for another 5 years and nothing would break.
Once that is defined, the tests and code pretty much write themselves~
Of course use a revision system in case it ever needs to be restored.
Wondering if I should just go ahead and get a new card.
SE++ Forum Battle Archive
Keep an eye on your credit card @infidel .
So the server will be down for a short bit.
I really don't need this much RAM
Drop your plan down and save money!
Unless you're already at the bottom, then rejoice cause hey, you can always use a little more RAM or something.
although also, when I first set up this VM, I was running both postgres and mysql, as well as a lot more php stuff, and I've consolidated everything into postgres and rewrote some of the php stuff into the python webapp, so overall memory usage had gone down anyway
Nice.
edit: same processor even (and that's not the E5-2670 they were talking about the new hardware running, but I don't know if they have any of those running just yet)
Because I think what happened was I was on 64-bit, did the migration, but it reset my kernel dropdown to latest 32-bit, causing KERSPLOSIONS.
Q1'09
that sounds like the right time frame for what I was running