Project: Outlook Add-in
PSO Devs code the the Add-in.
Core Development QAs test it.
- Win 7 32/64 + Outlook 2007 / Outlook 2010 32/64
- Win 8 Pro 32 / 64 + Outlook 2007 / Outlook 2010 32/64
- Win 8.1 Pro 32 / 64 + Outlook 2010 32/64
Service Packs available (if any)
- Add-in must provide direct access from Outlook to resources located on a server.
- Add-in must provide functionality 1:1 to the one available by accessing those resources through a web browser.
- Add-in should not break any Outlook functionality or the one provided by other Add-ins.
- PSO developers – 1 to 4 (on and off the project).
- PSO managers – 1 to 2.
- PSO QAs – 1 – (on and off the project).
- Core Development QAs – 1 to 4.
- Focus on rapid development, many small to medium sized projects (single project takes under 4 weeks to complete).
- Waterfall, no planning, short testing iterations.
- Requirements always clear and provided by the customer.
- QA engineers have supportive role – rarely consulted on how the customization/feature should behave – all is already written and signed by the customer.
- QA engineers and Developers are taken in and out of projects according to current demand.
- Developers (usually) run quick sanity checks of the code.
- No dedicated QA manager – Department director is the QA manager.
- Focus on core product development – long release cycles – two releases per year – one major and one maintenance release.
- Scurm / Agile, planning every 3/4/5 weeks, long testing iterations.
- Requirements are rarely clear.
- QA engineers have leading role in defining how given feature should behave.
- QA engineers and Developers focus on their corresponding tasks.
- Developers test their code and ensure basic functionality requirements are met.
- Dedicated QA manager.
- PSO decided what resource to use and when.
- Core Development decided what needs to be addressed / changed as fixes and functionalists.
- Neither team had experience with developing and testing Outlook Add-ins.
- Neither team had knowledge of the possible technological limitations that arise.
- First release date was mid October.
- Second release date was mid November.
- Actual release date was mid December.
- First estimate was that the project would take around 6-7 weeks + 30% buffer.
- Buffer ran out after the second week.
- ~ 445 Defects, of which 384 were successfully regressed and 61 were deferred, no Block/Major defects were left open.
- Add-in was released in mid December.
- Requirements were met at around 90%, no supported platforms were removed.
- People from either team met, talked, interacted, worked and had fun.
- There were a lot of reintroduced defects due changing the technology used (expected given the circumstances).
- No paper trail – the requirements for add-in were (only) verbally stated as having the same functionality which was available in the End User (Web) Interface. They were poorly understood. PSO did not explicitly ask for requirements and Core Development was not proactive to provide such anyway.
- First estimates were completely wrong given the fact that the project was deemed as “Red Alert” – meaning that this was a project with which PSO had absolutely no experience. Also this was the biggest project PSO have ever completed. Core Development insisted on at least doubling the estimates while PSO insisted on keeping them as they were. This lead to postponing the release several times.
- Culture clash (expected) – PSO Devs were used to having a leading role in what is implemented and how in terms of functionality and behavior, Core Development QAs were not entirely happy with that – fortunately and due the great people working for either team this was resolved quickly.
- PSO developers were working overtime. That’s never good.
- There was no single person entirely responsible for the release in either team – responsibilities were shared but that sharing was not a clear one and everyone was expecting the other party to act whenever necessary. Nobody acted and assumed full responsibility. Having one person responsible or clearly stated shared responsibilities is a must even if everyone have proven record of always meeting dead-lines and successfully leading projects.
- Planning alone is not enough, sometimes you have to improvise.:)
1. Open ssh_config / sshd_config – the first file is the configuration file for the client, the second is for the daemon (SSH server).
2. Uncomment Ciphers section and leave it as:
This will ensure that only aes128 and aes256-cbc ciphers will be used.
3. Add the following line:
This will ensure that this will be the only supported key exchange method.
4. To drop SSH packets with certain size you can always use the good old iptables:
iptables -A INPUT -p tcp -m length --length 1400:1500 --dport 22 -j DROP
This will drop all incoming packets with size between 1400 and 1500 for port 22 (the SSH port).
You can find the article here.
It’s a nice article which I sadly support but for different reasons. You see the issue is not in the current approach in terms of how you work (alone or with(in) a team) neither it is truly related to the incremental advances (which are actually pretty cool). No. It’s the plain old fear.
The thing is that in the past virtually all (of course not all 100%) great discoveries were carried by people and teams that DARED to be wrong. Right now what you have is a vast bunch of conformists, sticking to their financing, laying low, silent, fearful little creatures that follow the ‘general party line’, afraid not to make an honest mistake and be devoured by their peers. Furthermore honest mistakes are treated as fraud.
The faith of Stanley Pons, Martin Fleischmann and Jacques Benveniste was not that different than the one of J. Hendrik Schön. – despite the latter being a pure fraudster. Yeah, J. got his PhD revoked. Big difference.
As simple as that. Breakthroughs did not happen out of fear.
mysql -hhostname -uusername -ppassword db_name -e 'query to execute;'
- hostname – the host on which MySQL is installed
- username – the MySQL user that has the necessary privileges over the database
- passsword – the MySQL user password
- db_name – the name of the MySQL database that you want to query
- -e – MySQL option which will execute the statement and quit
- query to execute; – the MySQL query you want to execute enclosed in single quotes
Worth reading: Yes.Totally. A must to.
Word reading twice: At least 3 times. At least !
Writing style: Awesome.
Predominant feeling while reading it: joy, Joy, JOY !
Skipping pages: No. Are you insane – that’s a masterpiece !
Presence of SPAM: Absent.
Presence of useful information: 100%.
Topics covered: Scientific facts (yet to be refuted) about the way our brain operates…. and all the interesting consequences.
Application/Motto: Universal / Learn about your brain.
Conclusion: A must-read for everyone. Everyone. One of the few books that have only and solely useful information written in a wonderful way by a person that knows how to do it :). Done well done John Medina. That books is a masterpiece in every way.
p.s. One of the best things about this book is the lack of any (and I mean ANY) bullshit. The author is great – simply great. Buy this book, give it as a gift, read it !
Worth reading: Yes.
Word reading twice: Yes, even more.
Writing style: Magazine/Newspaper like. Had the feeling this was one very long and interesting article.
Predominant feeling while reading it: Joy.
Skipping pages: No.
Presence of SPAM: Very low. Mainly due the desire of the author to share additional stories / facts.
Presence of useful information: Very high.
Topics covered: (de)Evolution of our global economy (focus is on the Branding mania). Activism. Loosing jobs and creating ones with more-than-poor working conditions. Companies obsession with brand protection.
Application/Motto: Fuck branding (to the core).
Conclusion: A must-read for everyone who wonder what’s so bad about the WTO, globalization and the mash-up democracy + (very high) corruption in developing countries. Hopefully it will make you think twice before buying a new whatever that you don’t really need.
apg is a handy utility for creating random passwords / strings. To install it run:
apt-get install apg
The below for loop will create 300 random usernames / email addresses in the format email@example.com. You can always replace “domain” with “$i” , then you’ll have addresses in the format firstname.lastname@example.org.
-M – specifies that mode will be used
L – use small letters only mode
-n – number of passwords/random strings, in this case 300
for i in $(apg -M L -n 300); do echo $email@example.com >> fileToSaveResult ; done