Wednesday, March 23, 2005
Hmmm, this is my friend's final year project draft. He has few topics and he don't know which one to choose, anyone? Please don't hesitate to leave some useful comments, thanks.
data security :
ensure the data is not touch, lost, sniffed, decrypted,or hijacked in anyway. may use tunneling and data security conepts to protect the file. e.g. fingerprinting data.
voice encryption system :
as the name suggest, encrypting voice and mix with garbage. similar to data encryption.
RFID :
rfid integration into existing productivity sowftware or etc. but rfid is a very little part of computing. which it provide the API already.
bluetooth IM :
IM based on blue tooth, no existing messenger in bluetooth phones. existing users send msg by attaching msg in a notes and send the note to one phone only. it is sent by file. this solution will act as IM.
Grid Computing :
hard. a lot of research. uses concept of grid computing and p2p. individual can sell cpu power to someone who wants it. veyr limited resource.
mobile based/blutooth based filesharing :
personal file sharing sowftware that does not exist in the market.
Friday, March 04, 2005
Below is the project update after several meetings.
A. User Interface Layer
We always overlook this layer but actually it deserves more attention. Most of the articles I found from internet will recommend to adopt MVC design pattern, or using Microsoft User Interface Application Block (Fact is, this UIAB also using MVC pattern). I used MVC before and found it tedious as the codes are pretty long and I don’t have chances to experiment the power of MVC before I fucked up with boss. Anyway, Meili pointed out if we using MVC, porting the user interface layer’s logics between window forms and web forms become extremely (or seemingly) fast and easy.
B. Business Logic Layer
Business Model (BM) is nothing but used to hold the data, which will be passing across layers. Please refer to the reference link I provided as the article has more detailed discussion about the definition of model.
Business Process Components (BPC) is a set of logical functions that used to accomplish a single task. A straightforward example is order creation, which may consists of several steps, but in our case, the actual CRUD implementation will not be included over here, as this BPC is only a set of LOGICAL functions.
C. Data Access Layer
Business Process Components’ Data Access Components (BPCDAC) is the classes that do the actual CRUD implementation. (Please be note that which type of database will be using is transparent to BPCDAC).
Database Handler (DBH) is the place that decide which specific database handler should create, and calling the approriate database handler to perform CRUD, based on the configuration file or anything, a standalone XML configuration file (probably encrypted) or a text file, that resides in the application folder.
D. Framework
Process Observer (PCSO) is designed for uniquely carry all the returned messages or exception in the whole application domain. In short, whatever messages return from a process, the return type should always be the class in PCSO. Personally I would recommend using Interface if we want to have multiple PCSO classes.
Exception (EXP) I am facing a dilemma whether it should be inside Process Observer (based on the definition of PCSO) or standalone.
Common Utility (CU) What else? A set of commonly used tools (including UIL functionality such as CreateDropDownList)
Configuration Handler – Well, I am still thinking of its necessity as .NET provides a place to store all the application’s configuration information in a single file (app.config/web.config). If you guys think there is a need to derive our own configuration handler. It will then be taken out and include in the framework.
III. PROCESS FLOW
Allow me to give you a visual view of how the data will flows between layers (I have no time to come out with a sequential diagram as I am still studying it :P) This is the discussion result with Kang yesterday night. Anything that is irrelevant or incorrect please points it out.
1. Users trigger an event from user interface, and send the necessary information to BLL. In our case, information is one or more business models.
2. The event will then be handled by business logic components. Up to this step, process observer will create a unique observer container class in order to collect any information or exception that returns from any process that being called.
3. Based on the set of logical functions, it will then send the request (including the models and observer container) to business process components’ data access components. Touch-up works might carry out within these components and eventually it will then send the request (including the models and observer container) to DB handler.
4. DB handler will read the configuration in order to decide the proper database helper to call.
5. After appropriate helper is called, the specific DB helper will then do the dirty CRUD work, it might ranged from construct the proper stored procedure, construct the proper parameters, and so on.
6. After CRUD activities, the DB helper will return the observer class back to BLL for further process.
Please be note that any information, or exception that returned from step 2,3,4,5 will be stored in the observer class. This is also why I choose “Observer” as this observer will always pay attention to anything that happen (Just like your girlfriend…) within step 2,3,4 and 5 in order to return appropriate messages (in our case, an unique class that contains the messages) to BLL. Personally I think this observer class is the most fancy guy as how we design it will decide the flexibility, adaptability and extensibility of our application.
IV. OBJECT ORIENTED and DESIGN PATTERNS
This application will heavily using object oriented technology as I personally think this application give us a platform to refine our understanding towards fake OO design and true OO Design power. Inheritance, composition and polymorphism will be playing important roles in our case.
Design patterns that probably are using will be divided into three categories:
Creational Patterns
Singleton
Abstract factory
Structural Patterns
Adapter
Façade
Bridge
Behavioral Patterns
Observer
Strategy
Tuesday, March 01, 2005
After spending couple of weeks study the appropriate design of a reusable, highly adaptable framework Too bad I'm still having vague ideas about the actual design it should be. Therefore, decided to find some examples online and found .NET Petshop 3.0 and give it a try. Always, good and bad.
Good things is - This PetShop using ObjectPooling and EnterpriseServices for load balancing issues. This is where the part I can take out and this is also an .NET knowledge area, where I should improve myself. Besides, although they design DAL with the intention of "Extensibility" but it don't really that extensible. Yes, it extensible if there is no major changes in database. If so, bad for you as you will have to do a lot of touch-up works in your class.
So, my friend told me about the Axapta (MBS) way; well, pretty impressive and I think I gonna try it out myself tonight.
Cheers.
Friday, February 25, 2005
The product-service-system (or PSS) is a new term for an old idea: emphasizing access over ownership, it's simply 
about sharing products among people, and recognizing that bright green systems are just as important as products. Since we already take part in them - video rentals, laundromats, libraries, gyms, and taxis being obvious examples - we only really talk about PSS with regard to things that many of us don't usually share, like cars, appliances, tools, or clothing. Breaking past some of the cultural barriers that equate affluence with ownership may still be the greatest challenge, but what if alternative is cheaper, more sustainable, doesn't clutter your home, and connects you with your neighbours?
Ezio Manzini and Francois Jegou's online exhibition, Sustainable Everyday: Scenarios of Urban Life, is a picture of an urban community knitted together by their network of services. Making daily living more sustainable at the systems level, the scenarios focus on enabling the DIY spirit, and extending the home by externalizing some of its functions. The community shares access to little-used workspaces like professional-grade kitchens and workshops, leases connections to distributed green energy, and uses a mobility network that includes car-sharing, buses on demand, assisted hitching, and bicycle networks. Questioning why every house needed a separate lawnmower, Victor Papanek argued for tool-sharing thirty years ago; by observing that most power drills get used for no more than 20 minutes in their lifetime, Manzini and Jegou fit this scenario into a modern context.
"The exhibition deals with the future of “dwelling”... It does not focus on new ways in which technology could redefine traditional functions, but rather centres on the new “living strategies” that are emerging, becoming possible and, for some at least, desirable today. These are living strategies which result from social and system, rather than technological, innovation. It is these forms of social innovation that are at the centre of attention paid to new visions which are emerging and to the possible futures which could derive from them."
While some proposals, such as clothes-sharing, are unusual, it's worth recalling that designer handbags are being shared over the internet as readily as DVDs, and design students at TUDelft have been playing with these ideas for a decade. Sustainable Homeservices, an EU-based project, catalogues a whole range of mobility, security, and repair services available in European cities. As Jegou says in an interview in Dwell last year, "These solutions already exist in various forms - "Sustainable Everyday" merely brought them together. There's nothing sci-fi about it. For example, from Beijing we took the idea of the Lift Club, a sort of safe hitchhiking service organized by way of mobile text messaging. In Milan, we found a scheme among mothers so that kids can walk, rather than ride in cars, to school... All these things are banal locally, but when we introduce them elsewhere, they are innovations."
Much of Manzini's recent writing has outlined his hopeful observation that these kinds of systems are emerging organically within communities. Rather than predicting whether they will succeed, he's encouraging designers to shepherd them forward, improving their visibility and effectiveness.
What's new about product-service systems is that they're being seriously considered as an emerging business model, most famously by companies like Xerox and Interface. When a European policy organization like SusProNet works on PSS, it's to ensure that they're economically, as well as ecologically, viable. They're also describing a top-down approach that's much more arm's length than communal, but equally geared toward businesses taking responsibility for the impacts of their products.
UNEP's publication, Product-Service Systems and Sustainability (by Manzini and others, PDF download) breaks these ideas down exceptionally well: successful examples range from a Sicilian solar heating service, to Toronto, Canada's excellent AutoShare program, and GreenStar's solar-powered community centres. It also looks at PSS from a number of vantage points, including its potential pitfalls and - most excitingly - its leapfrogging potential in the developing world.
Original URL: http://www.worldchanging.com/archives/002198.html#more
Wednesday, February 23, 2005
Today when I was reading an MSDN article, which dicuss the proper way of data tier design . I noticed this graph which is very clear, and informative. Therefore, decide to take a note. By the way, this is a good example of "A good pictures worth thousand words"!
Today I read Daniel's blog and found this post. This is what he suggest to become a good programmer, what do you think?
- As with anything, time is the key. As the time passes, and you code, you'll get better. Don't expect to become a decent programmer in less than 4 years
- Find pet projects - even if you don't code a lot at college or at work, you can always get better by developing a project that you like. Don't worry if you will or won't be able to finish the project, and don't be scared about the size of the project. Even if you don't go too far in the project, you'll learn a lot
- You'll make a lot of mistakes, like we did. And you'll learn from that. More than you'll learn from things you think you did right
- Read a lot the programming forums and newsgroups. Read every message: there are all kinds of programmers there, often with the same problems you'll face
- Try to find a more experienced programmer to tell you if your code is good or not (and why!). If you can't, use us on the forums. Post small pieces of code and ask "is there a better way of doing this?" or "can you suggest me style improvements?"
- Talking about style, programming is all about style. Don't dismiss a better solution just because "my code is ugly, but it just works"
- Start with a simpler, but robust language. I strongly suggest you to start with C# or Java. Forget about C++, VB, VB.NET, Perl, Python, etc, until you're better and can understand why
- Read a lot about "best practices": this way your path will be shorter, as you won't spend time doing the same mistakes we did
- Read a lot of books. Even those cheap "Learn * in 21 days" can be good for starters, but after a while, try to find better books
- After a year programming, read a lot about OOP. This year without OOP will teach you why OOP is important
- After a year of OOP programming, read a lot about design patterns. This year without design patterns will teach you why design patterns are important
- Google is your friend. You need to be a Google master. Any good programmer should be able to find the needed information quickly
- Don't be ashamed to try things: "What if I cast this double variable to a char * ?". After you see things like this not working, try to understand why
Tuesday, February 22, 2005
Mention "Muji" to most Americans, and you'll get a blank look. Not from everyone, of course: a few will remember the brand from William Gibson's deliriously excellent Pattern Recognition, and those who have lived in Asia or Europe may nod wistfully, a look of dreamy longing in their eyes. Muji is a Japanese store which sells a variety of goods, from clothing to CD players to housewares, all under the philosophy of the company's full name: Mujirushi Ryhohin, "no brand, good product" (we posted about Muji back in December of 2003). While not explicitly a "sustainable design" outlet, Muji emphasizes simplicity, recycling and the avoidance of waste in its production and packaging. People who shop at Muji often become somewhat fanatical in their devotion. Muji is now applying its design philosophy to housing (Japanese page; rough English translation here). This strikes me as an interesting early indicator of something potentially big. What happens to the world of architecture when industrial designers, more accustomed to imagining new forms for coffee makers and laptops, turn their attention to the design of living spaces? After all, dwellings are just another kind of cultural artifact. What new insights might emerge?
Calton Bolick, an American on a long-term stay in Japan, wrote about discovering the new Muji demo home on a trip to Yurakucho:
As fellow expats from the San Francisco Bay Area, we both recognized the basic structure as essentially a loft (not new concept in the US, maybe, but new here) designed to fit Japanese-sized house lots and Muji shelving/furniture dimensions. It has an open atrium with the second level wrapped around it with floor-to-ceiling windows lighting up the main room. This model home had a kitchen centered around a stainless-steel island with an induction-heating range and ceiling hood: positively gigantic by Japanese standards and continent-sized in comparison to the pathetic kitchen arrangement inside my place. The upstairs had no interior walls, so you'd need curtains or shelving units to maintain some privacy, but nevertheless I was hooked. The cost is certainly reasonable: the base price is about ¥16 million (about $152,000 US), and with fixtures about ¥19 million (about $185,000 US). Of course, I'd need the land to put it on, but I kind of wonder if I couldn't buy the whole enchilada, pack it into a shipping container, and send it back to the US to be assembled there. And fill it with Muji furniture! And Muji appliances!.
See what I mean about those who shop at Muji? I've only been to Muji a few times, and I felt something of that same longing. Bolick's post gives a few more details, and includes some photos taken at the demo unit. The Muji "Infill" home doesn't stray too far from recognizable dwelling designs. This isn't all that surprising; a radical departure from traditional home design might not be the best first step, and Muji is more focused on making products simple than making them different. Still, this does feel like a distant early warning of a new trend. What would a Jonathan Ive-designed house feel like? Or one from Dominic Muren? This might also be a Viridian point of entry for wider application of LEED standards to residences: if the industrial designers turned architects adopt sustainable plans from the outset for their stylish ideas, the standards themselves have a good shot at catching some reflected cool. It's certainly a possibility -- I'll be watching this one closely.
Original URL: http://www.worldchanging.com/archives/002141.html#more
Meat-eating has impacted the evolution of the human body, scientists reported today at the American Association for the Advancement of Science's annual meeting in Washington, D.C. Our fondness for a juicy steak triggered a number of adaptations over countless generations. For instance, our jaws have gotten smaller, and we have an improved ability to process cholesterol and fat.
Our taste for meat has also led us into some trouble—our teeth are too big for our downsized jaws and most of us need dental work.
"It's really amazing what we know now that we didn't know 15 or 20 years ago," said Mark Teaford, a professor at Baltimore's Johns Hopkins University. Teaford helped organize a panel discussion on human diet from a number of perspectives:
• How did the ability to eat meat shape the evolution of humans?
• What can we learn about early humans from tooth shape?
Carnivorous humans go back a long way. Stone tools for butchering meat, and animal bones with corresponding cut marks on them, first appear in the fossil record about 2.5 million years ago.
How Did Meat-Eating Start?
Some early humans may have started eating meat as a way to survive within their own ecological niche.
Competition from other species may be a key element of natural selection that has molded anatomy and behavior, according to Craig B. Stanford, an ecologist at the University of Southern California (USC).
Stanford has spent years visiting the Bwindi Impenetrable Forest National Park in Uganda, Africa, studying the relationship between mountain gorillas and chimpanzees.
"It's the only forest where mountain gorillas and chimps both live," he said. "We're trying to understand the ecological relationship—do they compete for food, for nesting sites?"
The key difference between chimps and gorillas ecologically is that chimps eat meat and gorillas don't. A total herbivore is able to coexist with an omnivore because they have significantly different diets.
"From there we can extrapolate back to what two species of early humans may have done vis-à-vis each other two or three million years ago," Stanford said.
Better Fat Processors
When humans switched to meat-eating, they triggered a genetic change that enabled better processing of fats, said Stanford, who has worked extensively with gerontologist Caleb Finch of USC.
"We have an obsession today with fat and cholesterol because we can go to the market and stuff ourselves with it," Stanford said. "But as a species we are relatively immune to the harmful effects of fat and cholesterol. Compared to the great apes, we can handle a diet that's high in fat and cholesterol, and the great apes cannot.
"Even though we have all these problems in terms of heart disease as we get older, if you give a gorilla a diet that a meat-loving man might eat in Western society, that gorilla will die when it's in its twenties; a normal life span might be 50. They just can't handle that kind of diet."
Diet and Teeth
Tool-use no doubt helped early humans in butchering their dinners. But there is evidence that the advance to cooking and using knives and forks is leading to crooked teeth and facial dwarfing in humans.
Today it's relatively rare for someone to have perfectly straight teeth (without having been to the orthodontist). Our wisdom teeth don't have room to fit in the jaw and sometimes don't form at all, and the propensity to develop gum disease is on the increase.
"Virtually any mammalian jaw in the wild that you look at will be a perfect occlusion—a very nice Hollywood-style dentition," said Peter Lucas, the author of Dental Functional Morphology and a visiting professor at George Washington University in Washington, D.C. "But when it comes to humans, the ideal occlusion [the way teeth fit together] is virtually never seen. It's really the only body part that regularly needs attention and surgery."
Lucas argues that the mechanical process of chewing, combined with the physical properties of foods in the diet, will drive tooth, jaw, and body size, particularly in human evolution.
Essentially, by cooking our food, thereby making it softer, we no longer need teeth big enough to chow down on really tough particles. By using knives and forks to cut food into smaller pieces, we no longer need a large enough jaw to cram in big hunks of food.
"We're evolving to eat mush," said Bernard Wood, a paleoanthropologist at George Washington University.
Original URL: http://news.nationalgeographic.com/news/2005/02/0218_050218_human_diet.html
Monday, February 21, 2005
Guys,
We had a discussion this morning. It's good to see that everyone is raising their opinions, meanwhile I also noticed there is some confliction regarding the intention of doing this project. Please allow me to talk a little bit more in this email.
The nature of a community is , when someone raise up a topic and we discuss about it, we can always hear sound of perfection, and sound of reality, on the other hand. This is good as we have diverse ideas that make us think, and plan a little bit more before we actually carry out an activity. In my opinion, personally I would say Ngan is a 70% realism, and 30% pefection; Kang is a 55% perfection, 45% realism, and I, myself is 90% perfection, but always lack of thinking of realistic issues, which I give myself a poor 10%. Based on the conversation we had just now, I can feel that everyone has their points of focus, and perhaps, somewhat over emphasize a portion, and over raising the porportion of an individual aspect.
So, I think what we should doing is try to think simple at first, some like this "We just gonna start up a new project, a lite version of ERP, that will including Accounting, Inventory and Ordering modules". That is our major target at the first place. So, no hard feeling, right? How we do it? utilise the knowledge we gain from our works. How can we do it? Using VB.NET, or C#.NET. Like I said I am a 90% perfectionism; therefore what arose in my mind is how we gonna accomplish this project; I was overlook the issue of whether it is sellable, or not. Well, I am not trying to protect my points here but somewhat, isn't that good we just kick start the project and we will see along the way we go? Thousand miles begin with a single footstep! Therefore, we have to convince ourselves before we can convince others that we are doing a kinda ERP "prototype".
So, in short, we gonna develop a lite ERP, and it will include three major modules. Points of interests include:
1) Improving your OO knowledges
2) Improving your business thinking/rules
3) Improving your UML
4) Improving your coding (VB/C#)
Isn't that good? So, anyone interested to involve in this project?
Regards,
HoneyNET
I was discussing with my partners about the GNU GPL. And after all I found that we are not clear with the terms and conditions that we must follow in order to use a GPL licensed IDE to develop a non-free software.This is what I found about the FAQ of GNU GPL ( General Public License) thingy.
Below are the excerpts I taken down from the FAQ, which I found it pretty informative;
How do I get a copyright on my program in order to release it under the GPL? (Just wonder, does it apply to Malaysia?) Under the Berne Convention, everything written is automatically copyrighted from whenever it is put in fixed form. So you don't have to do anything to "get" the copyright on what you write--as long as nobody else can claim to own your work.
However, registering the copyright in the US is a very good idea. It will give you more clout in dealing with an infringer in the US.
The case when someone else might possibly claim the copyright is if you are an employee or student; then the employer or the school might claim you did the job for them and that the copyright belongs to them. Whether they would have a valid claim would depend on circumstances such as the laws of the place where you live, and on your employment contract and what sort of work you do. It is best to consult a lawyer if there is any possible doubt.
If you think that the employer or school might have a claim, you can resolve the problem clearly by getting a copyright disclaimer signed by a suitably authorized officer of the company or school. (Your immediate boss or a professor is usually NOT authorized to sign such a disclaimer.)
Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them?
Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.
Some programs copy parts of themselves into the output for technical reasons--for example, Bison copies a standard parser program into its output file. In such cases, the copied text in the output is covered by the same license that covers it in the source code. Meanwhile, the part of the output which is derived from the program's input inherits the copyright status of the input.
As it happens, Bison can also be used to develop non-free programs. This is because we decided to explicitly permit the use of the Bison standard parser program in Bison output files without restriction. We made the decision because there were other tools comparable to Bison which already permitted use for non-free programs.
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library.
Can I use the GPL for something other than software?
You can apply the GPL to any kind of work, as long as it is clear what constitutes the "source code" for the work. The GPL defines this as the preferred form of the work for making changes in it. (Note: This one is pretty funny, "Source Code",so even "flirting a chick in 10 days can also be "GPL"ed!!!)
However, for manuals and textbooks, or more generally any sort of work that is meant to teach a subject, we recommend using the GFDL rather than the GPL.