li feng (lifeng007)'s Public Profile in the Diigo Community

Member since Sep 24, 2008, follows 5 people, 8 public groups, 482 public bookmarks (483 total).

More »

Tags

Recent Tags:	c++(0), java(0), linux(0), mysql(0), css(0), web(0), data(0), Twitter(0), tcp(0), voa(0), English(0), python(0), uml(0), 关系图(0), margin(0), padding(0), return(0), 箴言(0), AOP(0)
Top Tags:	c++(45), java(38), python(32), linux(21), google(17), install(11), mysql(9), web(9), pie(8), flash(8)

More »

Recent Bookmarks and Annotations

Web services Programming Tips and Tricks: WSDL file imports about 20 hours ago
My Tracks for Android on 2009-11-20
Google Labs on 2009-11-20
Application Fundamentals | Android Developers on 2009-11-16
- if your application needs to display a scrolling list of images and another
  application has developed a suitable scroller and made it available to others,
  you can call upon that scroller to do the work, rather than develop your own
- Android applications don't
  have a single entry point for everything in the application (no main()
  function, for example). Rather, they have essential components that
  the system can instantiate and run as needed
What is Android? | Android Developers on 2009-11-16
- operating
  system, middleware and key applications.
Einstein’s Secret to Amazing Problem Solving (and 10 Specific Ways You Can Use It) on 2009-10-09
- Rephrase the Problem
  
  When a Toyota executive asked employees to brainstorm “ways to increase their productivity”, all he got back were blank stares. When he rephrased his request as “ways to make their jobs easier”, he could barely keep up with the amount of suggestions.
- Every problem — no matter how apparently simple it may be — comes with a long list of assumptions attached
- 13 more annotations...
- - The first step to get rid of bad assumptions is to make them explicit.
  - go further and test each assumption for validity: think in ways that they might not be valid and their consequences.
  - Before rushing to solve a problem, always make sure you look at it from different perspectives
  - Looking at it with different eyes is a great way to have instant insight on new, overlooked directions.
  - How would your competition see this problem? Your employees? Your mom?
  - Use Effective Language Constructs
  - instead of finding ways to ‘quit smoking’, you may find that ‘increase your energy’, ‘live longer’ and others are much more worthwhile goals.
  - Make It Engaging
  - One thing is to ‘increase sales’ (boring), another one is ‘wow your customers’. One thing is ‘to create a personal development blog’, another completely different is to ‘empower readers to live fully’.
  - One trick that usually helps when you’re stuck with a problem is turning it on its head
  - If you want to win, find out what would make you lose. If you are struggling finding ways to ‘increase sales’, find ways to decrease them instead
  - “You never listen to me”, the solution is not obvious. However, if the statement is “You don’t make enough eye contact when I’m talking to you,”
  - It is said that a well-defined problem is halfway to being solved: I would add that a perfectly-defined problem is not a problem anymore.
Continuous Integration on 2009-09-25
- The one prerequisite for a developer committing to the
  mainline is that they can correctly build their code. This, of
  course, includes passing the build tests.
Evolutionary Database Design on 2009-09-24
- One of the primary features of agile methods is their attitude
  towards change. Most of the thinking about software process is about
  understanding requirements early, signing off on these requirements,
  using the requirements as a basis for design, signing off on that, and
  then proceeding with construction. This is a plan-driven cycle, often
  referred to (usually with derision) as the waterfall approach
  
  Such approaches look to minimize changes by doing extensive
  up-front work. Once the early work is done, changes cause significant
  problems. As a result such approaches run into trouble if requirements
  are changing, and requirements churn is a big problem for such
  processes.
- One of the primary features of agile methods is their attitude
  towards change. Most of the thinking about software process is about
  understanding requirements early, signing off on these requirements,
  using the requirements as a basis for design, signing off on that, and
  then proceeding with construction. This is a plan-driven cycle, often
  referred to (usually with derision) as the waterfall approach
  
  Such approaches look to minimize changes by doing extensive
  up-front work. Once the early work is done, changes cause significant
  problems. As a result such approaches run into trouble if requirements
  are changing, and requirements churn is a big problem for such
  processes.
- 8 more annotations...
- - One of the primary features of agile methods is their attitude
    towards change. Most of the thinking about software process is about
    understanding requirements early, signing off on these requirements,
    using the requirements as a basis for design, signing off on that, and
    then proceeding with construction. This is a plan-driven cycle, often
    referred to (usually with derision) as the waterfall approach
  - Instead of thinking of design as a phase, which is mostly
    completed before you begin construction, you look at design as an
    on-going process that is interleaved with construction, testing, and
    even delivery. This is the contrast between planned and evolutionary
    design. One of the vital contributions of agile methods is that they
    have come up with practices that allow evolutionary design to work in
    a controlled manner. So instead of the common chaos that often happens
    when design isn't planned up-front, these methods provide techniques
    to control evolutionary design and make them practical.
    li feng on 2009-09-24
    
    how to in controlled manner ?
    Why we need to change the design ?
  - iterative development
  - During this project we started with iterations of a month, but after a
    few months changed to two week iterations which worked better
  - One of the tenets of agile methods is that people with
    different skills and backgrounds need to collaborate very closely
    together. They can't communicate mainly through formal meetings and
    documents. Instead they need to be out talking with each other and
    working with each other all the time.Everybody is affected by this:
    analysts, PMs, domain experts, developers... and DBAs.
  - In these cases this data's been extracted from prior legacy
    systems with automated data migration scripts. Obviously you can't
    migrate all the data right away, as in early iterations only a small
    part of the database is actually built. But the idea is to iteratively
    develop the migration scripts just as the application and the database
    are developed iteratively. Not just does this help flush out migration
    problems early, it makes it much easier for domain experts to work
    with the growing system as they are familiar with the data they are
    looking at and can often help to identify problem cases that may cause
    problems for the database and application design
  - On our large project we gave
    ourselves some extra breathing space by waiting a week before making
    the database change
  - By breaking down all
    the database changes into a sequence of small, simple changes; we've
    been able to make quite large changes to production data without
    getting ourselves in trouble.
Design Principles from Design Patterns on 2009-09-21
- An
  interface is free from implementation details, and it defines the vocabulary of the
  collaboration. Once I understand the interfaces, I understand most of the system.
- I guess the core of my question about "program to an interface, not
  to an implemenation," is this: In Java, there's a special kind of class called
  interface that if I'm writing I put in code font—the Java
  interface construct. But then there's the object-oriented interface concept,
  and every class has that object-oriented interface concept.
- 4 more annotations...
- - If I'm writing client code and need to use an object, that object's class exists in some type
    hierarchy. At the top of the hierarchy, it's very abstract. At the bottom, it's very concrete.
  - The way I think about programming to interfaces is that, as I write client code, I want to
    write against the interface of the type that's as far up that hierarchy as I can go, without
    going too far.
  - Every single one of those types in the hierarchy has a contract.
  - Something can be public, but that doesn't mean you have
    published it.
Design Principles from Design Patterns on 2009-09-21
- n. Fortunately, with today's refactoring support you no
  longer have to come up with an interface up front. You can distill an interface from a
  concrete class once you have the full insights into a problem. The intended interface is
  just one 'extract interface' refactoring away.
- it also separates the really valuable part, the
  design, from the implementation
- 4 more annotations...
- - . One question is whether you should always use a Java
    interfaces for that. An abstract class is good as well. In fact, an abstract
    class gives you more flexibility when it comes to evolution. You can add new behavior
    without breaking clients.
  - As a consequence when adding a new method to an interface you
    have to do so in a separate interface
  - In Eclipse we take API stability seriously and for
    this reason you will find so called I*2 interfaces like IMarkerResolution2
    or IWorkbenchPart2 in our APIs. These interfaces add methods to the
    base interfaces IMarkerResolution and IWorkbenchPart.
    Since the additions are done in separate extension interfaces you do not break the clients.
    However, there is now some burden on the caller in that they need to determine at run-
    time whether an object implements a particular extension interface.
  - I don't envision a software archeologist finding an Eclipse
    installation stored somewhere on a hard disk in ten or twenty years. I really mean that
    Eclipse should still be able to support an active community in ten or twenty years.

More »

Groups

Coders

317 members, 1595 items

A group for and about coders and programming -- theory, practice, and research.
DataPortability

19 members, 164 items

Designing, Implementing and Evangelizing the Data Portability Blueprint in Concrete Terms.
International Business and Trade Group

134 members, 716 items

Welcome - This is a place where people can exchange their views and information on business matters! Get answers and counseling from other fellow members!
Journalism

36 members, 315 items

A group to collect interesting links from the world of journalism, which is undergoing major change as it struggles to find a business model that will carry it into the digital future.
The Apple Group

549 members, 1392 items

This is the group for everything Apple. From Mac Mini to the iPhone...