Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Separate Testing Envs, hold merges til post-UAT (Score 1) 313

I have had this problem in several different projects with different teams.

I generally think of it as the "code hostage" or "cherry-picking" problem. You have the work of 15 issues reviewed and merged and loaded up and running on a test environment. For 14 of those issues, a "user" ( or whatever you call the non-developer issue-owner in this case ) checks in and says it is good. Time is passing and the 15th person is a no-show. It's worse than if they said it still wasn't fixed -- then you would immediately go to work reverting that code change and re-testing everything -- but instead everything is held up in limbo.

One way to address the majority of these issues, is to set up a separate testing environment or server per ticket, and put the pull request or branch on it, before it is merged to the main branch. Force users to test BEFORE it gets on the path that will end up in a deployment. This means that slow moving people won't block others.

This might seem expensive, but with APIs to cloud hosting and/or container technology, it can be automated, and is a lot cheaper than it would have been a few years ago.

You can still end up with a problem on the now integrated code, and still have to cherry-pick / revert some commits, and since the result has not yet been tested all together, you still have to re-test. However this happens much less often, because it is only happening in the cases where interaction between different work is causing the problem.

Comment Nice job . . . (Score 5, Insightful) 421

. . . . . . reminding us that those buying IoT devices don't own anything useful, and that your f**cking GARAGE DOOR OPENER could be dependent not only on Internet connectivity but the continued willingness of a service provider (Garage Door Operation As a Service--GDOAAS?) to provide service, at whatever cost they deem fit. I'll leave my light bulbs, refrigerator, door locks, garage door opener, and thermostat off the Internet, thank you very much.

Comment Okay, here are my thoughts (Score 1) 303

1. If you're doing a shed, then the windows and door should be secured; get keypad/key lock, self-locking, that saves you a lot of "did I lock the door", and "where's the key" questions. Get some security bars for the windows without making it feel like jail. Consider shatter-proof windows, or a nice steel mesh if you want to open the windows in good weather. Google some options. Get a steel door and steel door jambs if you won't want someone to kick in the door.
2. Put in some sturdier material on the walls other than half-inch plywood. Insulate, vapor barrier, etc. Make sure you have a solid foundation and water-proof where the wood may be in contact. Keep the shed 1-2 inches off the ground.
3. Get some proper electrical wiring and a shut off switch, or a sub-panel. If you want backup batteries, a consumer UPS won't do the trick especially if you want a rack of servers.
4. If you run cable from the house to the shed, do it undergound, use pvc piping and go at least 2 feet undergound. Run at least two cables and a string/wire to fish more in the future.
5. Get a good view without being distracted and bothered by glare.
6. Splurge on good flooring.
7. Figure out what your ideal desk arrangement is and build the shed accordingly (U-desk, L-desk,
8. Get cable locks
9. Backup to a location inside the house or "cloud"
10. Build a quality roof.
11. Sound-proof, especially the roof.
12. Have a security camera pointed a the shed and inside it if you can

Slashdot Top Deals

The reason computer chips are so small is computers don't eat much.

Working...