Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Amateur level fail (Score 4, Interesting) 85

"The Honeywell Tuxedo Touch Controller web interface uses JavaScript to check for client authentication and redirect unauthorized users to a login page."

You'd think that a company like Honeywell would know better about security, especially as they have a whole cyber security division...
This is like the pages that had a crappy javascript password which you could read by seeing view source, if you knew the keyboard shortcut (right click would be blocked on javascript).

Mistakes an amateur would make.

Comment Re:Who uses virt floppy anymore (Score 3, Informative) 95

From the article:

Floppy drives are outdated, so why are these products still vulnerable?
For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default. And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

Comment Good communication (Score 1) 261

A good work environment is one where people trust you and you trust them. Trust comes from communication. And I mean the clear communication that has a clear objective and purpose, not the management buzzword bingos that fill in meeting time.
Everything ends up tying back to good and positive communication.

Some insights:

- Setup an IRC chat. We tried many other group chat systems before, and we always come back to IRC. Choice of clients help as everyone will have their preference. There are also a lot of bots that can help also make it a more central communication hub. We have it with both our monitoring software and our build system. This help cut down on the noisy chatter in a dev area.

- Make sure that accomplishments are visible to the rest of the company. (If you follow real Agile/Scrum, that's your sprint review). This will help avoid the "cost center" label that brings underfunding.

- See if you can accomodate hardware/software requests. It makes no sense denying a well paid programmer a 200$ ram upgrade that can speed up his work.

- Bad news will happen. Your job will be to deal with it and to bat for your team. Don't throw them or a team member under the bus.

- Make sure the rest of the company communicates with your before going to bother your team. If need be, get a Scrum Master.

- You'll probably read a lot about offices vs open areas vs cubes. Cubes are a sucky halfway system. Open areas is better for communication but introduce distractions. Offices cut down on distractions but tend to create silos of knowledge. The best I've seen is an open area with offices available for meetings. If possible, get an open area that is not shared with non team members.

- Break down silos. Avoid having specific team members always working on the same system or module in the code. Its true that work will get done quicker by having the silo, however if when something breaks and that person is unavailable, its going to be much harder to fix it.

- Reviews: If the only focus of HR with the reviews is to have a paper trail when someone needs to be de-hired, they will always suck. Done properly, they are tools that can help your team members grow. You can ask your team member to fill out the form in a self-evaluation way, then have a meeting with them to see how their view of themselves compare to yours.

- Breaks are important. Be it coffee, lunch, paid break, evenings, weekends. They matter.

- Overtime only works for about 2 weeks, after that, the productivity level goes back down to pre overtime rates. There are numerous studies on this that have been published.

- Make sure that your team has all the tools needed to do proper QA. If your production environment is load balanced, then the QA must be load balanced.

- Whiteboards should be easily accessible, with plenty of fresh markers. At least have 2 more then the size of the team plus you. Whiteboard paint isn't so good as its much harder to clean to do the orange peel effect.

- Team lunches are nice, get some budget for them.

- If need be, fire the bad apple in the team. If someone is always disruptive, produces low quality code, keep messing up, is rude, you need to let them go. It sucks and its a very hard thing to do.

Agile / Scrum:
If you follow it this is critical:
- Do not skip the retrospective. This is critical as that is the way the team will improve.
- Make sure that all changes to a sprint go through the PO. The PO will need to remove the equivalent amount of work from the sprint. Ensure this happens.
- Internally, plan a buffer of time for miscileanous improvements. Let the team decide and take charge of that time. Do not let additions to a sprint chew up that time.


Comment Re:First and foremost (Score 5, Interesting) 176

Also look at oursources payroll, time tracking (this is sometimes a must for R&D tax credit) and make sure you have some financing / funding lined up. You need to have a plan to cover the first 2 years of operations where revenue will be slim.
This will also allow you to avoid getting into the "anything for a buck" mentality.

Don't focus on development tools / standards. Let your programmers take care of that. You might want to look for a lead developer with experience managing junior / intermediate developers.

Comment Re:Help! Help! (Score 1) 865

There is also no "bugless" mechanical system for that matter. Mechanical throttles have gotten stuck, brakes can fail, especially if they are poorly maintained. Poor maintenance usually kills mechanical systems, poor practice and poor programming create bugs. However software that is written will always behave in a definite pattern. Mechanical system will fail differently with different effects.

The systems:
- Switch to neutral or reverse
- Parking brake
- Brake override
- Push button quick presses
- Push button long press
- Speed limiter

If NONE of the system works, then I'd have to concentrate on not crashing for about 30 to 60 minutes, then the battery will run out. I'd crank the heat and open the windows to increase energy usage and drag to speed up the process.

If there is a passenger, they might be able to pull the emergency fuse plug from the rear seat floor.

Comment Re:Help! Help! (Score 1) 865

Nissan supports both long press and push multiple times (3 times I think).

I've had the Nissan push button since 2009 and love it. No fuss, no issue, always started / turned on the first time.

On the Leaf it will also shift to Neutral if I press the park button while in Drive.
Worst comes to worst, it wouldn't take too long to drain the battery pack if all else fails.

Comment Re:The answer, in short, is "NO" (Score 2) 716

Also the building companies know how much time is required to build a wall and every step of the way is time budgeted. If you wait too long to put the next brick on the mortal, it would be too dry and won't hold the brick. If you don't mix the mortar components long enough, then it might not hold up properly. Also the end product is very well known in advance (eg size, mortar color, brick colar, rows of bricks, etc). The customer agrees to the wall on paper before the work starts and can't go back saying "that is not what I meant when I said 5' high, its too high now and I don't like it " and expect it to be fixed for free. Each job is uniquely done for a specific customer to that customer's specs. Customer also tend to understand it that there is a certain way to do it.

The problem often times with software is that there is pressure to cut costs (less people, less time), cut time to delivery, cut tools, change requirements all the time, etc. The builders of software are rarely listened when it comes time to fix problems. Technical debt accumulates with every change that is done on a temporary basis just to satisfy the customer quickly.

Going back to the analogy, no one would ask a builder once the wall is built that brick at position 5,10 is not the right shade of color, change it now. Yet we expect this from software all the time. If builders would change all the bricks in a wall it would most likely fail.

Comment Re:Last about five years? (Score 5, Interesting) 237

My experience tends to mirror Backblaze, both with my own personnal business and as an employee at 2 different companies.

Seagates would always fail prematurely, but usually in a way that is noticeable through SMART monitoring. Interestingly it matches up with when they acquired Maxtor, which also started going bad when they bought Quantum. With my colocated servers for my side business I used to have to go at least twice a month to replace a failed drive. I eventually gave up on Seagate and replaced all but 1 drive (a spare raid member) with a mix of WD and Hitachi. I'm also really pissed at Seagate to have slipped so much in reliability, especially with their 7200.11 and early 7200.12 drives.

WD would fail sometimes, near when they were new. Where I worked previously, we had a policy of mixing new and old WD drives in a new server. It was a lenghty process but helped avoid losing a simple RAID1 setup.

Hitachi very good and usually inexpensive.

Where I'm working now we're trying out Toshiba and so far one drive failed out of 12, but that sample size is way too small and its not been long enough to truly tell how it will go.

Comment Re:MongoDB--run away (Score 2) 372

I would call it experienced, same as me.

Where I work, someone had the bright idea that since you could stuff arbitrary data in mongo (for example multi dimensional arrays) that it should be the proper way of doing it.

So now I'm stuck untangling a website that manages millions of pieces of data in about 860 documents or so...

There are also various interesting issues that happen if you have a collection that start with _
Its only possible to edit it through the api, and not the command line mongo shell. The bug was open about 3 years ago and has yet to be addressed. Things like that make me feel that there is still a lack of maturity where it counts.

Comment Re:Users don't hate agile... (Score 1) 597

The problem is that a lot of companies think that agile is to have daily stand up meetings and keep changing the requirements or what will be delivered.

Once you have all the components (Scrum team, product backlog, sprint goals, sprints, daily meetings, retrospective, etc) things fall in very nicely as it gives the business people the answers they need (ROI mainly), what is commited to (a sprint) at a set cost (sprint length).

One of the easiest tool to estimate effort and business impact is to use relative value. Set something as x and rate the benefit/cost around that x for the other tasks. This gives a lot of leeway to business people to shift priorities to make sure that the team works on more valuable features first. The scrum team is also responsible for communicating back to the business people how much a feature will cost vs another feature.

Lastly the retrospective is one of the most cut out part of scrum, and it is actually the worst one to cut out. It is there to look at what happenend and figure out how to improve the team and get the team working efficiently. I've had quite a few of those meetings that ended up with the scrum master deciding to cut out specific members because they would fail to follow basic rules (like not overwriting someone's else work in svn). It gives a structured way to voice concerns about how things are going and the quality of the individuals that make the team.

Comment Kid Mode and Baby Toy (Score 1) 311

Baby Toy is a small app that just has some pictures of animals, musical instruments or robots and it makes sound / vibrates when one of them is touched. It has an option to lock into the app until some specific combination is pushed so it's very hard to get out of it.

Kid Mode is a shell that provides some apps that are age appropriate. We got a cheap white label tablet (7") and put it on it. It's pretty good and can wrap around other kid apps so that they can't get out of the kid mode / app easily.

We've mainly used both on planes and places where it gets hard to bring lots of toys. I do agree with the comments about sleep and melatonin production, whenever she used our phones / tablets near her sleep time it was harder to get her to sleep. We're now more careful about that.

Comment Re:solve your problem small (Score 2) 276

Escalating is probably not going to help, and in most likeliness will hurt your career at that company.

1. This could be an opportunity for you to climb the ladder so to speak, even becoming one of the chiefs. At some point you'll need to angle things to become chiefs-of-chiefs between the other chiefs and your PM. However make sure the project can succeed with the setup, otherwise you'll get the blame.

2. You could also try to stay an indian, but that might mean you get canned with the rest of the team if the project goes wrong.

3. Transfer to another department if possible.

Comment Standards are good, (Score 2) 430

That's why everyone has their own...

There are some standards / practices that are very important when it comes to making secure code. They avoid basic mistakes and so on. There should also be some minimal enforcement in terms of how to indent which always help to reread the code. Peer review for anything complex is also a good practice.

As for camel case, or hungarian notation, I feel that they are mainly a waste of time in the best of case. Being pedantic about code isn't going to help anyone or any project, in fact it might make a lot of talented people leave the company.

Comment Re:Why TekSavvy? (Score 1) 172

The big ISPs all have interest in the fight as their parent companies tend to own producers of content (Quebecor and Videotron, Shaw and Global, Bell and CTV, etc). They also are distributors of media (cable, satellite and IPTV).

With some collusion it would be quite easy to have the big media target a smallish ISP (teksavvy being one of the biggest small players) to test the waters, set some legal precedants and see how the market reacts.

Slashdot Top Deals

The trouble with doing something right the first time is that nobody appreciates how difficult it was.