azizkhani.net

I know that I know nothing

create trustStore from .cert file

clock June 8, 2014 20:09 by author Administrator

 

keytool -import -file C:\certificate.cert -alias firstCA -keystore myTrustStore

 



create client-side web service using wsimport

clock June 6, 2014 13:00 by author Administrator

 

create java code

wsimport -keep -verbose soap.wsdl

 

 

create jar file

wsimport -clientjar wsclient.jar soap.wsdl

 



Reusable components in AngularJS

clock June 4, 2014 21:14 by author Administrator
angular.module('components', []).directive('category', function () {
return {
    restrict: 'E',
    scope: {},
    templateUrl: '/Scripts/app/partials/CategoryComponent.html',
    controller: function ($scope, $http, $attrs) {
        $http({
            url: "api/FeaturedProducts/" + $attrs.catName,
            method: "get"
        }).success(function (data, status, headers, config) {
            $scope.Cat = data;
        }).error(function (data, status, headers, config) {
            $scope.data = data;
            $scope.status = status;
        });

    }
}
});

CategoryComponent.html
<a href="#/Categories/{{Cat.CategoryName}}">
    <h4>{{Cat.CategoryName}}</h4>
</a>
<div ng-switch on="status">
    <div ng-switch-when="500" class="alert alert-error">
        {{status}}
        {{data}}
    </div>
    <div ng-switch-default>
        <ul class="unstyled columns">
            <li class="pin" ng-repeat="p in Cat.Products">
                <a href="#/reviews/{{p.UPC}}">
                    <h5>{{p.ProductName}}</h5>
                    <img src="{{p.ImageUrl}}">
                </a>
            </li>
        </ul>
    </div>
</div>


usage
<ul class="unstyled">
    <li>
    <category cat-name="Ultrabooks"></category>
    </li>
    <li>
    <category cat-name="Tablets"></category>
    </li>
    <li>
    <category cat-name="Laptops"></category>
    </li>
    <li>
    <category cat-name="Digital SLR Cameras"></category>
    </li>
</ul>


Checked or Unchecked Exceptions?

clock June 3, 2014 22:58 by author Administrator

Some Java books(*) covering exceptions advice you to use checked exceptions for all errors the application can recover from, and unchecked exceptions for the errors the application cannot recover from. In reality most applications will have to recover from pretty much all exceptions including NullPointerException, IllegalArgumentExceptions and many other unchecked exceptions.



The differences between checked and unchecked exceptions are:

  1. Checked exceptions must be explicitly caught or propagated as described in . Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown. Basic try-catch-finally Exception Handling

  2. Checked exceptions in Java extend the java.lang.Exception class. Unchecked exceptions extend the java.lang.RuntimeException.

 Checked

public class BadUrlException extends Exception {
        public BadUrlException(String s) {
            super(s);
        }
    }


public void storeDataFromUrl(String url){ try { String data = readDataFromUrl(url); } catch (BadUrlException e) { e.printStackTrace(); } } public String readDataFromUrl(String url) throws BadUrlException{ if(isUrlBad(url)){ throw new BadUrlException("Bad URL: " + url); } String data = null; //read lots of data over HTTP and return //it as a String instance. return data; }

Unchecked:
public class BadUrlException extends RuntimeException { public BadUrlException(String s) { super(s); } }

public void storeDataFromUrl(String url){ String data = readDataFromUrl(url); } public String readDataFromUrl(String url) { if(isUrlBad(url)){ throw new BadUrlException("Bad URL: " + url); } String data = null; //read lots of data over HTTP and //return it as a String instance. return data; }


Open multiple Eclipse workspaces on the Mac

clock January 27, 2014 17:26 by author Administrator

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




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

clock January 26, 2014 21:49 by author Administrator

 

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

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

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

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

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

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

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

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

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

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

 



Good vs Bad Leader

clock January 10, 2014 21:48 by author Administrator

 

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.


 



21 signs of BAD MANAGERS

clock November 23, 2013 19:23 by author Administrator

 

 

  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.

 

 



Applying the 80:20 Rule in Software Development

clock November 16, 2013 18:58 by author Administrator

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



Thomas Edison

clock October 14, 2013 22:15 by author Administrator

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



About the author

 Welcome to this web site . 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

Sign In