I am going through a couple of interesting documents:
This one contains many word of wisdom about strategic approach to parametrization of the JVM...
http://www.javacodegeeks.com/wp-content/uploads/2013/06/JVM_Troubleshooting_Guide.pdf
for instance it's valuable the advice to distinguish applications where mostly short-lived object are created (most Service Bus applications are like that) from Applications which keep long lived objects - for instance HTTP sessions. In the first case, you should adjust the Heap to give more space to the Young generation space. In the second case, give more space to the Tenured space.
This document also contains valuable tips and tools:
http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/toc.html
Sunday, January 11, 2015
Friday, January 9, 2015
Vodafone uk possibly the worst support for offshore customers ever encountered
My pay-as-you-go number all of a sudden can't connect any longer to any network,
I have tried several times to connect to My Vodafone web application, always got "invalid login or password", or very weird error messages showing some internal ADF error code...
tried several times to reset the password to no avail
tried reaching for many days in a row the online help chat, it always shows as unavailable:
Live Chat. When you want. Chat to us without having to use your phone. Our support advisers are available online - 24 hours a day, 7 days a week.
spent some 35 minutes calling (international call!) the +447836191919, always getting the "we are really busy at the moment, sorry for the delay" recorded message....
You would expect such %&"#! support from some really obscure brand, not from one of the major mobile networks... if I were in the UK I would run immediately to the competition... I think I will simply forgo my UK number at this point...
PS I forgot one more hurdle: if you don't have a Credit Card with a billing address in UK, forget about being able to topup...
Ah of course there is no way to simply drop an email or send a message with a web form... it would be too simple...
PS I am checking with Lebara to migrate the Vodafone number to them.... With Lebara they do support by email, much more convenient!
I have tried several times to connect to My Vodafone web application, always got "invalid login or password", or very weird error messages showing some internal ADF error code...
Index: 0, Size: 0 ADF_FACES-60097:For more information, please see the server's error log for an entry beginning with: ADF_FACES-60096:Server Exception during PPR, #14
tried several times to reset the password to no avail
tried reaching for many days in a row the online help chat, it always shows as unavailable:
Live Chat. When you want. Chat to us without having to use your phone. Our support advisers are available online - 24 hours a day, 7 days a week.
spent some 35 minutes calling (international call!) the +447836191919, always getting the "we are really busy at the moment, sorry for the delay" recorded message....
You would expect such %&"#! support from some really obscure brand, not from one of the major mobile networks... if I were in the UK I would run immediately to the competition... I think I will simply forgo my UK number at this point...
PS I forgot one more hurdle: if you don't have a Credit Card with a billing address in UK, forget about being able to topup...
Ah of course there is no way to simply drop an email or send a message with a web form... it would be too simple...
PS I am checking with Lebara to migrate the Vodafone number to them.... With Lebara they do support by email, much more convenient!
Saturday, January 3, 2015
End of my 3.2 years contract on a OSB integration project.... lesson learned.
1) from day 1, get a wiki. NOTHING should simply be documented in emails. Just write all technical info in a wiki and distribute the link to the wiki. We used Confluence wiki: it's simply fantastic. Same goes for documents: just attach them to a wiki page and circulate the link.
2) from day 1, store all configuration in a CMDB. Forget stinky property files or yaml or xml: you need a real relational DB. I had countless discussion on this topic with people who wanted all into property files... forget it, real life is different.
3) enforce the rule that ALL code should be subject to code reviews. Some people were allowed to run loose on the ground and work separately from the rest of the team, and their work turned into a maintenance nightmare, because it was not adhering to the standards. It cost us a fortune to fix the issues once in production.
4) use GIT (we were using stash) rather than SVN: the learning curve is steeper, but you get so much more out of it
5) have fun in the project. Fun really helps making everybody life better. Avoid being harsh with people - it generally only makes things worse. Just talk to people calmly, try to understand the underlying issues. Of course there are a few bastards - usually they are only a tiny minority - who simply don't want to work: either ignore them, or ask management to fire them, but don't get mad.
6) don't do the work that other people are supposed to do. You will get exhausted, and finally you will not do the work that YOU are supposed to do. And eventually management will not even notice your extra effort. Just flag issues, assign tasks and carry on.
7) automation is excellent, but some things are simply too intrinsically complex or variable to be automated. Learn to accept that some stuff will simply HAVE to be done manually. Automation comes with a cost, so learn to balance cost and benefits.
8) keep it simple. Some tools like Java allow you to make complex things in a reliable way, some others (like Puppet) not. If you use primitive tools, do primitive stuff.
9) JIRA is great. Use it. Don't abuse it. JIRA is a tool, not an end in itself. You are paid to make things work in Production, that's all what matters.
10) there are a hundred different methodologies to slaughter post-it against a wall and inebriate yourself with SCRUM ideology. Usually none of all this actually solves a problem. If you are unlucky enough to fall in an Agile-fanatic community, just smile and say yes.
11) avoid by all means MEETINGS. 99% of the issues can be solved with a phone call. If a meeting is still REALLY required, send an invite with an agenda of points to discuss, a link to a wiki, and after the meeting circulate the minutes. Any discussion who is not strictly on the agenda should be vigorously quelched.
12) a limited amount of technical books (electronic format) can be beneficial, to create a common culture and promote continuous education.
2) from day 1, store all configuration in a CMDB. Forget stinky property files or yaml or xml: you need a real relational DB. I had countless discussion on this topic with people who wanted all into property files... forget it, real life is different.
3) enforce the rule that ALL code should be subject to code reviews. Some people were allowed to run loose on the ground and work separately from the rest of the team, and their work turned into a maintenance nightmare, because it was not adhering to the standards. It cost us a fortune to fix the issues once in production.
4) use GIT (we were using stash) rather than SVN: the learning curve is steeper, but you get so much more out of it
5) have fun in the project. Fun really helps making everybody life better. Avoid being harsh with people - it generally only makes things worse. Just talk to people calmly, try to understand the underlying issues. Of course there are a few bastards - usually they are only a tiny minority - who simply don't want to work: either ignore them, or ask management to fire them, but don't get mad.
6) don't do the work that other people are supposed to do. You will get exhausted, and finally you will not do the work that YOU are supposed to do. And eventually management will not even notice your extra effort. Just flag issues, assign tasks and carry on.
7) automation is excellent, but some things are simply too intrinsically complex or variable to be automated. Learn to accept that some stuff will simply HAVE to be done manually. Automation comes with a cost, so learn to balance cost and benefits.
8) keep it simple. Some tools like Java allow you to make complex things in a reliable way, some others (like Puppet) not. If you use primitive tools, do primitive stuff.
9) JIRA is great. Use it. Don't abuse it. JIRA is a tool, not an end in itself. You are paid to make things work in Production, that's all what matters.
10) there are a hundred different methodologies to slaughter post-it against a wall and inebriate yourself with SCRUM ideology. Usually none of all this actually solves a problem. If you are unlucky enough to fall in an Agile-fanatic community, just smile and say yes.
11) avoid by all means MEETINGS. 99% of the issues can be solved with a phone call. If a meeting is still REALLY required, send an invite with an agenda of points to discuss, a link to a wiki, and after the meeting circulate the minutes. Any discussion who is not strictly on the agenda should be vigorously quelched.
12) a limited amount of technical books (electronic format) can be beneficial, to create a common culture and promote continuous education.
Subscribe to:
Posts (Atom)