I think Google Pagerank is what defines what most of us see whenever we search for something on the web. Being such an important gateway between someone and the information. Does it have biases? How much censorship does it do ? How many false positive happen for the spam filtering? and so many other questions.
The agile way is to keep it as a backlog item until the PO feels its time to fix it. The real way is to listen to what front line support say and fix it when the noise becomes too much. If its not a priority for anybody, then no one cares about the bug.
I'm not sure why but they are missing the Toxic manager in there. I used to have a manager that would ensure that whoever he nominates to be the lead on a project would fail to accomplish most, if anything in the project. First very unrealistic time tables for the project, which was essentially a rewrite of an existing CMS from scratch. 3 months. He booked easily 60% of my time in various meetings. Spent a lot of the rest of the time planning and designing features to "stay ahead of the curve". Of course during that time I still had to make sure that the legacy systems still worked. Then pulls me aside to say that "my" team feels that its weird that I am not programming on the rewrite. And of course, keep changing who is on the project team to ensure complete discontinuity.
Then came the low performance review and this is when I realised how much of a shaft was waiting for me. I quickly transferred to another team within the company and a recruiter thankfully called my cell phone shortly after.
Essentially the manager I had stayed in place because the team was responsible for generating most of the revenue for the business and he always had someone to preassign the blame.
2 years after I resigned he was made the lead of a new team. Those team members refused to work with him within the first month. HR eventually wisened up and looked at the part performance reviews and exit interviews that targeted that manager, he was demoted and told that he can keep working in his corner until he can find a job at another company.
The major lesson I learned is to never tolerate a bad manager. As soon as you can, leave.
The problem is now that the bullshit rules are now expected by customers. When we did our last major UX review, we didn't have those rules in place. Adding them made our customers overall feel more confident in our platform.
Its the same as when you have a supervisor that cannot be trusted or that sets you up to fail so that he looks good. I left his team for another team within the company, thankfully that was relatively easy. This allowed me to gather my wits around me and a few months later I left for a much better job at a company that actually listens to their developers.
In the exit interview I made it abundantly clear that I left because of the bad supervisor, and I also took the time to praise the new one in the other team. I learned through the grapevine that the bad supervisor was eventually assigned a whole new team to start a new project. A few weeks in, they _all_ refused to keep working with him. Eventually HR reviewed his file and realize the toxicity he brought with himself. He got reassigned to a "special project team" and made it clear to him he won't be doing anything else until he left.
In the late 90s, I decided to do some A/B testing to see which method worked best for myself. I had 6 classes for a term, 3 of them I took handwritten notes, and 3 of them I took typed notes.
I've never been much of a crammer and usually relied on rereading the notes once or twice prior to an exam. After the midterms, I've noticed that I had a higher score for all 3 classes with handwritten notes, so the next thing I did was to ditch the laptop. One thing I love about handwritten notes is that I can visualize myself having written them and found that it helps recall the information. On the laptop, it was much harder.
Even with classes where the teach provided typed out notes (or printed out powerpoint slides), I would continue to write my own notes in a big binder of loose sheets.
Classes are there for learning, not to transcribe what the teacher says.
Even now at work, I use pen and paper at meetings. Laptops and computers just get in the way and provide way too many distractions.
This is over the Internet (car has an EDGE connection) and does not require a line of sight.
Thankfully, its a pure electric car. If it turns on its just an inconvenience. If this was on a gas car, it could kill people with carbon monoxide poisoning.
I regularly use the LEAF in -25C weather and its fine. The heater does put quite a bit of drain on the battery, but the distances I do are manageable. I also regularly use the remote HVAC feature on battery, too bad the Nissan app is a buggy UX nightmare.
"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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ford has an all electric version of the Focus and also has 2 extended ranges hybrid (C-Max Energi and Fusion Energi), and as far as I remember they are all under 40k too.
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.
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.
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.
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.
From what I remember reading ADS-B is also going to be used where there is no RADAR coverage, over the oceans etc.
It will also be used to communicate to other aircrafts the position of an aircraft, this could be another major source of problems with spoofing communications.
Slashdot Mirror
I think Google Pagerank is what defines what most of us see whenever we search for something on the web. Being such an important gateway between someone and the information. Does it have biases? How much censorship does it do ? How many false positive happen for the spam filtering? and so many other questions.
The agile way is to keep it as a backlog item until the PO feels its time to fix it.
The real way is to listen to what front line support say and fix it when the noise becomes too much.
If its not a priority for anybody, then no one cares about the bug.
I'm not sure why but they are missing the Toxic manager in there.
I used to have a manager that would ensure that whoever he nominates to be the lead on a project would fail to accomplish most, if anything in the project.
First very unrealistic time tables for the project, which was essentially a rewrite of an existing CMS from scratch. 3 months.
He booked easily 60% of my time in various meetings. Spent a lot of the rest of the time planning and designing features to "stay ahead of the curve".
Of course during that time I still had to make sure that the legacy systems still worked.
Then pulls me aside to say that "my" team feels that its weird that I am not programming on the rewrite.
And of course, keep changing who is on the project team to ensure complete discontinuity.
Then came the low performance review and this is when I realised how much of a shaft was waiting for me. I quickly transferred to another team within the company and a recruiter thankfully called my cell phone shortly after.
Essentially the manager I had stayed in place because the team was responsible for generating most of the revenue for the business and he always had someone to preassign the blame.
2 years after I resigned he was made the lead of a new team. Those team members refused to work with him within the first month. HR eventually wisened up and looked at the part performance reviews and exit interviews that targeted that manager, he was demoted and told that he can keep working in his corner until he can find a job at another company.
The major lesson I learned is to never tolerate a bad manager. As soon as you can, leave.
The problem is now that the bullshit rules are now expected by customers. When we did our last major UX review, we didn't have those rules in place. Adding them made our customers overall feel more confident in our platform.
Its the same as when you have a supervisor that cannot be trusted or that sets you up to fail so that he looks good.
I left his team for another team within the company, thankfully that was relatively easy. This allowed me to gather my wits around me and a few months later I left for a much better job at a company that actually listens to their developers.
In the exit interview I made it abundantly clear that I left because of the bad supervisor, and I also took the time to praise the new one in the other team.
I learned through the grapevine that the bad supervisor was eventually assigned a whole new team to start a new project. A few weeks in, they _all_ refused to keep working with him. Eventually HR reviewed his file and realize the toxicity he brought with himself. He got reassigned to a "special project team" and made it clear to him he won't be doing anything else until he left.
Wait, didn't something similar exist in the past, call Type of Service field?
https://en.wikipedia.org/wiki/...
Of course its been deprecated, for obvious reasons.
In the late 90s, I decided to do some A/B testing to see which method worked best for myself. I had 6 classes for a term, 3 of them I took handwritten notes, and 3 of them I took typed notes.
I've never been much of a crammer and usually relied on rereading the notes once or twice prior to an exam.
After the midterms, I've noticed that I had a higher score for all 3 classes with handwritten notes, so the next thing I did was to ditch the laptop.
One thing I love about handwritten notes is that I can visualize myself having written them and found that it helps recall the information. On the laptop, it was much harder.
Even with classes where the teach provided typed out notes (or printed out powerpoint slides), I would continue to write my own notes in a big binder of loose sheets.
Classes are there for learning, not to transcribe what the teacher says.
Even now at work, I use pen and paper at meetings. Laptops and computers just get in the way and provide way too many distractions.
This is over the Internet (car has an EDGE connection) and does not require a line of sight.
Thankfully, its a pure electric car. If it turns on its just an inconvenience. If this was on a gas car, it could kill people with carbon monoxide poisoning.
I regularly use the LEAF in -25C weather and its fine. The heater does put quite a bit of drain on the battery, but the distances I do are manageable.
I also regularly use the remote HVAC feature on battery, too bad the Nissan app is a buggy UX nightmare.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ford has an all electric version of the Focus and also has 2 extended ranges hybrid (C-Max Energi and Fusion Energi), and as far as I remember they are all under 40k too.
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.
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.
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.
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.
From what I remember reading ADS-B is also going to be used where there is no RADAR coverage, over the oceans etc.
It will also be used to communicate to other aircrafts the position of an aircraft, this could be another major source of problems with spoofing communications.