This is very strange problem i faces as per me. May be because different email clients have different encodings or something else, but we will get encoded filename header from some email clients like lotus, blackberry phone etc.
Message header for attachment:
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
Content-Disposition:attachment;
filename="=?Windows-1252?B?SU1HMDAwMTYuanBn?="
Then i was stucked with the thing that how to decode the filename.I have the filename only in subject line.But i can not trust that because say if 3 attachments are there, then there will be 3 filenames in subject in order.But we should not depend on the subject of the email.javax.mail.internet.MimeUtility util class which helps to decode the encoded strings in message header values as belowMethod:javax.mail.internet.MimeUtility.decodeText(strValueToBeDecoded);
But most of the encodings with java 1.3.1 are not supported. At least 1.4.1 must be used.
This is no new thing i am writing about.All developers know this and gone through this when ever they got some new thing to develop. It hurts in heart when someone says something which you must do as a process and feels boring.
As per SDLC, some basic steps needed for developers are,
Reading specs and use cases
This is most annoying thing i ever found. Yes because what the analysis team does all knows. Copy-paste some basic paragraphs from the templates,making funny and ugly diagram in word which is never usable to developers,using fast vivid colors which will just make you cry or feels you are reading some horror story and finally the language which is too complex and contains thing which are not of use! What they mention you can't get and what you want them to know they can't deal with it!
Deciding approach & Making design diagrams
This is somewhat very important thing if the team is well. Otherwise all are just suggesting diff. approaches and no decisions at the end!Design diagrams must be prepared before the development but sometimes the project managers or the CEOs are in so hurry that they want get it done fast and deployed even without any Technical documents/design diagrams!
Sometimes the coder submits the diagrams and docs for review but the leaders/seniors are so busy (or may be ignoring it thinking 'its not related to my project') and not reviewed it.And after the code is done, they will find holes and design problems in that.Now say who's fault is this?
This is cool when its a small thing and approach is simple, but when you are expecting a whole big feature/module/functionality in short period ,with testing yes keep this in mind "with testing" done,then its a hell for developer. After the coding done, developer asked for diagrams. Now say, isn't its boring? Yes that what i am saying. It sucks!
Coding
Its best part if the thing is designed and design is reviewed properly.As per my experience this is the least time taking step for a good team.
Code Review
CR must be done. But if its done in quite short time after the code done. it means, CR should be fast process of all because developer can complete task fast if its in period while he is inside the thing.Once he had given for CR and you get back to him after some 1 month or so then he even doesn't remember what he had done!
And at some places, quite boring procedures for CR. you submit code filenames for CR, distribute it to some person,write comments on it and etc... This is time wasting and it stinks! It must be a simple process like pressing a button because developers' time is not for this funny things.
Deployment
This may be complex thing but it should not waste coders time. But at some places, system people stuck and call for coders.Some are intelligent to get into but some are even not understanding on total help and documentation provided by a coder.Only the instructions needed to be given by a coder.Its not his job to deploy the whole titanic into the sea!
Testing
Now is the worst thing that a developer may be need to do sometimes.Yes i have done this even more than hundreds times because of some funny and frustrating test cycles! Sometimes they even don't know how to test & What should they do!You can say its better you do it all instead giving them the idea.This is mostly happens because nowadays testing people are nontechnical! They just know clicking the button and etc.They don't know how to deal with application internals and view log and all.May be companies wants some nontechnical arts graduate as a tester in less money instead of a good testing software engineer!
And sometimes they raise wrong bugs which have been tested with wrong scenarios,even on your instructions that this is not right one to test!And when you draft a mail which makes them shy or some senior person bang on them, they feels you like an enemy!
Bug fixing
This is most 'long long long' process for coders.The diff. natured(technical/nontechnical,thinking themselves as coders) testers rais long list of bugs out which rare cases are function issues.Most are like for UI things.And when a coder is given a bug which not of his area then definitely it will consume more time and if we calculate total time for such non-related-area bugs of all coders then it will make a big difference in the process completion date.May be it can delay release if the testing cycles are more in numbers but less detailed and proper.
This is not like i am bored of coding. I love coding but everything which is having its charms,have some bad things also associated with it.Say if testers are also coders then? may be you can get more bugs? yes but you can test fats and at the end your final release would be a great thing.Same thing applies for all team in SDLC ;). i mean analysis,project management,testing all.
I am telling what i think. It depends on particular's likings ;)
Just do Code.
Relo helps developers explore and understand large codebases. Developers often face code that is hard to understand with over half their time being spent on understanding code. Relo allows developers to easily create relevant and intuitive diagrams, along with features to help automatically build diagrams based on the users past navigation.
While Relo diagrams are similar to UML, they also allow developers to zoom in to view details and edit the code using embedded text editors. These diagrams represent only a small manageable part of the code and do not include irrelevant details, thus allowing a developer to focus on important code relationships.
