Open multiple Eclipse workspaces on the Mac

by Administrator 27. January 2014 17:26

At the command line, navigate to your Eclipse installation. For example:

cd /Applications/eclipse/

or wherever you installed Eclipse to.

Once there, launch Eclipse as follows:

./eclipse &

This will launch eclipse and immediately background the process.


example cd /azizkhani/Download/eclipse/Eclipse.app/Contents/macos


Tags:

public

درد یک پنجره را پنجره ها می فهمند

by Administrator 26. January 2014 21:49

 

درد یک پنجره را پنجره ها می فهمند

معنی کور شدن را گره ها می فهمند

سخت بالا بروی ، ساده بیایـــــی پایین

قصه ی تلخ مرا سرسره ها می فهمند

یک نگاهت به من آموخت که در حرف زدن

چشم ها بیشتر از حنجره ها می فهمند

آنــچه از رفتنت آمد بــــــه سرم را فـــردا

مردم از خواندن این تذکره ها می فهمند

نه نفهمید کســــی منزلت شمس مرا

قرن ها بعد در آن کنگره ها می فهمند

 

Tags:

public

Good vs Bad Leader

by Administrator 10. January 2014 21:48

 

ContextGood LeaderBad Leader
Responsibility A good leader always takes responsibility of his project. If the project fails, he knows he’s the one to blame and he has the courage to admit it. A bad leader knows it can’t be his fault, so he channels his energy into proving his team was the culprit, or maybe just some members he doesn’t like anyway.
Hard-work A leader is a role-model for his team members. He’s working at least as hard as any other team member. Just because he’s the authority, it doesn’t mean he has to work only what he enjoys, leaving the ugly stuff for the rest of the team. A bad leader has had enough already. Why he should write code anymore when you have all these guys at your service.
Mentoring A good leader always mentors his junior team members. He doesn’t let them fail with difficult assignments. He knows that investing in his team will definitely bring a return of investment in the form of quality. A bad leader doesn’t care about this stuff. The less experienced members should be hardened through tough tasks.
Respect A good leader respects all his members, no matter how skillful they are. He knows that there is only one way to lead a team, and that’s through respect, not fear. A bad leader doesn’t respect anyone but himself. He may laugh when someone makes a mistake, that’s going to be reported the upper management anyway.
Climbing the company hierarchy A good leader believes in skills and professionalism. He does his job and expects to earn the right position he deserves. A bad leader doesn’t have many skills, but he’s a master bootlicker. As much as he despises his subalterns, he’s constantly flattering his superiors.
Anger management A good leader is emotionally mature, so he knows how to control his feelings. He doesn’t scream at his team, or threatens them in any way. A bad leader likes to show his rank, and what could be a better way if not through intimidating his team. He knows that fear is a great motivator.
Trust A good leader trust his team members. He knows he’s working with intelligent individuals that couldn’t have made it here otherwise. That’s why he encourages everybody to push themselves out of their knowledge comfort zone, so they could end up learning more, and becoming better. A bad leader doesn’t trust anyone but himself. And those less experienced developers shouldn’t be given anything but writing documents, or probably doing some unit tests for the code he writes. After all, who likes all that hassle of testing perfectly written code anyway.
Task assignment A good leader chooses those tasks everybody is running away from. He gives an example when assigning himself laborious tasks everybody’s had enough of. A bad leader always chooses the tasks he likes best. Maybe it’s a new framework he would love trying out, and why would anyone give up on such a pleasant experience. If he finds it to too difficult, he can then pass it to his team, to fix the remaining issues.
Reporting issues A good leader tries to do his best to overcome any difficulty. But there are times when this is not enough, so he immediately reports the situation to his upper management, so proper action may be taken. A bad leader always masks issues. He doesn’t like to report them, since that may affect his good reputation. If the problem arises he will try to find someone to blame, as it can’t ever be his fault.
Code Reviewing A good leader believes in code review and encourages his team to take part into reviewing others’ work. When recurrent issues arise, he writes them into a shared knowledge blog, so that everybody can learn better ways of tackling a given problem. A bad leader doesn’t have time for reviewing, and everybody is on his own anyway. If someone breaks something, the bad leader will simply tell on him.
Frustration A good leader may have been led by a bad leader, and he promised himself he wouldn’t ever be that guy. He is mature enough to learn from others’ mistakes. A bad leader wants others to suffer as he suffered when he was himself a junior.
New ideas A good leader likes to listen more than talking. He let all his team members participate in any brain-storming session. He knows that great ideas may pop-up from where you’d expect less. A bad leader doesn’t like when others show off their so-called good ideas. His ideas are better anyway. And if he hears an interesting opinion, he may laugh at it, and then go to the upper management praising what he’s just come up with.


 

Tags:

public

21 signs of BAD MANAGERS

by Administrator 23. November 2013 19:23

 

 

  1. Bias against action or against planning, simply waiting or postponing for ever; embrace the status-quo
  2. Secrecy, not willing to share information. giving the feeling that having access to information is a privilege reserved to managers
  3. Working very long hours to prove hard work or hide incompetence
  4. Over-sensitivity, someone that reacts immediately but the reaction is not a real response but mostly an emotional fact
  5. Brain washed by procedures and processes; favor a process instead of getting things done
  6. Expect the people to read they minds; hand in hand with secrecy –  i keep the info for me and then blame people for not acting
  7. Preference for weak employees or candidates, feeling threatened by the super-competent employees or candidates
  8. Focus on small tasks, missing the big picture and favoring details  on a specific task where he is competent
  9. Inability to hire former employees: none of his former colleagues were convinced to join him in his new company or he is simply someone that never mentored anyone or never took time to inspire anyone that can trust him
  10. Not setting  deadlines, the work is done when is done …why bother with time boxed iterations
  11. Favoring consultants instead of growing his staff
  12. Letting his employees feel like an anonym and irrelevant person that does not make any difference if stay or go
  13. Not measuring and not giving feedback based on real metrics and expectations previously communicated and clarified (not on feelings and emotions)
  14. Not telling people what he is expecting from them
  15. Micromanaging
  16. Sneaky boss – someone that is continuously acting or talking behind his employees’ backs so they are never sure where they stand
  17. Managing his boss more than growing his staff , and this is sometimes ok, but in general only to protect his staff or the company from bad decisions coming from superior management
  18. Divide and Conquer – strong believer in internal competition more than in the internal collaboration
  19. Ignoring non-performers – usually we are tempted to build on strengths and recognize top performers, but at the end “A chain is only as strong as its weakest link”
  20. Stealing credit – if we win I will stick my name at the top, if we loose it is definitely because the team is not mature enough or understaffed or ….simply “acted without my knowledge, they need some control”
  21. Not believing that  HIS JOB IS TO BUILD THE TEAM AND THE ORG, AND THE TEAM AND THE ORG WILL FIGURE OUT HOW TO BUILD THE PRODUCT !!!
    My product as a dev manager is the ORG and/or the TEAM.

 

 

Tags:

Applying the 80:20 Rule in Software Development

by Administrator 16. November 2013 18:58

80:20 Who uses What, What do you Really have to Deliver

Another well-known 80:20 rule in software is that 80% of users only use 20% of features. This came out of research from the Standish Group back in 2002, where they found that:

  • 45% of features were never used;
  • 19% used rarely;
  • 16% sometimes;
  • only 20% were used frequently or always.

 

http://java.dzone.com/articles/applying-8020-rule-software

Tags:

agile | public

Thomas Edison

by Administrator 14. October 2013 22:15

Time is really the only capital that any human being has and the thing that he can least afford to waste or lose…

Tags:

agile

What is a software quality?

by Administrator 5. September 2013 21:12

Quality(T) = Changeability(T) / Known defects(T)

What can we say about software quality and defects?

  • Software quality is inversely proportion to the number of defects in the system: high quality implies few defects and vice versa
  • Defects have undesirable consequences
  • Defects incur costs, in all likelihood financial costs but there are others, time in particular. Even if defects are not fixed they will incur costs, e.g. over payments from a financial system or people ringing the helpline to report a spelling mistake
  • Removing defects requires rework and rework costs time and money

define “Easy to change”

  • Change is localized
  • Change is less error-prone – perhaps better stated as “change does not inject defect” (Somewhere in Jones writing he suggests 7% of defect fixes inject new defects so high quality software would have a bad fix injection rate less than 7%)
  • Change is more maintainable, i.e. changing software does not detract from the changeability of the software

Tags:

public

design pattern

by Administrator 30. June 2013 20:43

 

  • Don’t use patterns unless you need to.
  • Don’t use patterns that you don’t fully understand.
  • Don’t expect that whoever is going to work on the code in the future to recognize and understand the patterns that you used – stick to common patterns, and make them explicit in comments where you think it is important or necessary.
  • When you’re changing code, take some time to look for and understand the patterns that might be in place, and decide whether it is worth preserving (or restoring) them: whether doing this will really make the code better and more understandable.

ref:http://java.dzone.com/articles/design-patterns-after-design

 

Tags:

design pattern

Leadership in Software Development

by Administrator 19. May 2013 21:14

 

 

Leadership within the software development industry can be a tricky area. All teams require some level of leadership. Promoting members within a team or organization is a practical choice, but skills so highly sought after in development don't always translate into good leadership. Developers are very logical and analytical. In the world of DiSC, which is a behavior assessment tool, most programmers fall into the D (Dominance) or C (Conscientiousness) categories. These individuals are direct, accurate, and task oriented. Although these traits might seem appropriate there are many other facets to leadership. Unfortunately, most individuals are thrust into leadership roles with little experience or guidance. Regardless of the situation, members in leadership roles must take the responsibility seriously. Leadership is a continuous journey of learning, teaching, and growing. Knowing this, how does one gain those abilities?

There are a few standard answers to this question. First, everyone receives the opportunity to learn on the job. Although this method works, the road can be difficult to navigate without a map. Second, ask for book recommendations about leadership. Everyone has at least one favorite they can recommend. Third, find a good mentor. Having a proper mentor is an invaluable resource. Don't be afraid to ask individuals if they have time to sit and talk about leadership. Most don't realize the accommodating nature of mentors. Sometimes they forget that those individuals were once in their shoes.

The last option is the most difficult to achieve because good mentors are hard to find, but there are other avenues. Recently, Chick-fil-A® held their annual Leadercast conference. This one-day event tackles leadership through the knowledge and experience of industry experts and seasoned veterans. One can travel to the actual event or view it at a simulcasted location. The 2013 event featured Jack Welch, Andy Stanley, Coach Mike Krzyzewski, John C. Maxwell, Dr. Henry Cloud, LCDR Rorke Denver, Gold Metal Olympian Sanya Richards-Ross, David Allen, and Condoleezza Rice. The sessions were a rich combination of presentation and interviews. Events like this create a sponging effect where years of knowledge and insight are soaked up. Documentation of each session becomes vital to encourage the flow of information, but still allows time for reflection and maturation. Below are a few highlights from the 2013 event:

"The key in complexity is to see simplicity."
Some also refer to the quote: "Complexity is simplicity done well." These simple references highlight the importance of finding simplicity in each task required.

"You don't need to be the smartest person in the room."
This is an important reminder for leaders. One doesn't need to answer all the questions or always have the best idea. Empower others to make decisions and utilize the outstanding skills of each team member.

"Yesterday is gone... let go of yesterday."
This is a reminder to not let the sins of the past control the future. Mistakes are only bad if they are not used as a tool for learning. Keep a consistent eye on the future.

"Get it out of your head."
Develop a system to keep track of things. This system must be outside of the brain in a notepad or task list. If left in the brain, one will spend either too much time or not enough on each task. The brain excels at tackling one item at a time.

"If everything is important, then nothing is important."
Leaders usually have an overflowing plate of tasks and responsibilities. It's important to have a narrowed focus, while inhibiting everything else. This applies to the team's progress as well.

"Rules don't lead."
Don't attempt to build and enforce rules. Work with teams to devise standards that everyone will hold themselves too. Rules are meant to be broken; standards are meant be exceeded.

 

ref:http://java.dzone.com/articles/leadership-software

Tags:

agile

Weblogic fast-swap

by Administrator 17. May 2013 22:23

This is something that could eat up time in any bigger project. If you make changes to your working application and you need to track down bugs, it's inevitable to redeploy your application on any change. What is done in seconds, if you
a) know the WLS administration and/or
b) your application is quite lean

If you have a fullblown JEE application with all the magic inside, it's no problem to wait for a successful redeployment for minutes.
In practice there are some ways to get rid of this overhead very quickly.

1) Weblogic's ChangeAwareClassLoader (WLS <=10.x)
Java classloaders do not have any standard mechanism to undeploy or unload a set of classes, nor can they load new versions of classes. In order to make updates to classes in a running virtual machine, the classloader that loaded the changed classes must be replaced with a new classloader. When a classloader is replaced, all classes that were loaded from that classloader (or any classloaders that are offspring of that classloader) must be reloaded. Any instances of these classes must be re-instantiated. If you deploy an exploded application and run the WLS in development mode, you can take advantage from the ChangeAwareClassloader. If you make changes to a single class, the WLS simply replaces the whole classloader and starts over with your newly created class. This was one of the first approaches to quicker development roundtrips. Anyway it is still not the solution for bigger applications.

2) Weblogic Fast-Swap (WLS >=10.x)
Java EE 5 introduces the ability to redefine a class at runtime without dropping its ClassLoader or abandoning existing instances. This allows containers to reload altered classes without disturbing running applications, vastly speeding up iterative development cycles and improving the overall development and testing experiences. The usefulness of the Java EE dynamic class redefinition is severely curtailed, however, by the restriction that the shape of the class – its declared fields and methods – cannot change. The purpose of FastSwap is to remove this restriction in WLS, allowing the dynamic redefinition of classes with new shapes to facilitate iterative development.

With FastSwap, Java classes are redefined in-place without reloading the ClassLoader, thereby having the decided advantage of fast turnaround times. This means that you do not have to wait for an application to redeploy and then navigate back to wherever you were in the Web page flow. Instead, you can make your changes, auto compile, and then see the effects immediately.
 

    • FastSwap is only supported when WLS is running in development mode. It is automatically disabled in production mode.
    • Only changes to class files in exploded directories are supported. Modifications to class files in archived applications, as well as archived JAR files appearing in the application’s classpath are not supported.


To enable FastSwap in your application, add <fast-swap>true</fast-swap> to the weblogic-application.xml file.

FastSwap can also be enabled for a standalone web-application by adding the <fast-swap> element to the weblogic.xml file.

Once FastSwap is enabled at the descriptor level, an appropriate ClassLoader is instantiated when the application is deployed to WLS. It is recommended that you have your IDE setting set to "compile-on-save" so that java files are compiled on saving. The FastSwap agent tries to find all classes that have been modified since the last iteration by looking at all directories in the classpath.

FastSwap is supported with POJOs (JARs), Web applications (WARs) and enterprise applications (EARs) deployed in an exploded format. FastSwap is not supported with resource adapters (RARs).

 

Supported changes:
    • Addition and Removal of static methods
    • Addition and Removal of instance methods
    • Changes to static and instance method bodies
    • Addition and Removal of static fields
    • Addition and Removal of instance fields
limitations:
    • Java Reflection results do not include newly added fields and methods and include removed fields and methods. As a result, use of the reflection API on the modified classes can result in undesired behavior.
    • Changing the hierarchy of an already existing class is not supported by FastSwap. For example, either a) changing the list of implemented interfaces of a class; or b) changing the superclass of a class, is not supported.
    • Addition or removal of Java annotations is not supported by FastSwap, since this is tied to the reflection changes mentioned above.
    • Addition or removal of methods on EJB Interfaces is not supported by FastSwap since an EJB Compilation step is required to reflect the changes at runtime.
    • Addition or removal of constants from Enums is not supported.
    • Addition or removal of the finalize method is not supported.


When FastSwap is enabled, after you recompile a class, FastSwap attempts to redefine classes in existing classloaders. If redefinition fails because your changes fall outside the scope of supported FastSwap changes, the JVM throws an UnsupportedOperationException in the WLS window and in the server log file. Your application will not reflect the changes, but will continue to run.

ref:http://blog.eisele.net

Tags:

j2ee | public | weblogic

About the author

 Welcome to the web site of Azizkhani. This page has two purposes: Sharing information about my professional life such as articles, presentations, etc.
This website is also a place where I would like to share content I enjoy with the rest of the world. Feel free to take a look around, read my blog


Java,J2EE,Spring Framework,JQuery,

Hibernate,NoSql,Cloud,SOA,Rest WebService and Web Stack tech...

RecentPosts

Month List