Wednesday, November 01, 2006
Sunday, October 29, 2006
Interface and Abstract Class
Program to an Interface -- Doubts
http://forum.java.sun.com/thread.jspa?threadID=735991&messageID=4229194
Interface vs Abstract Class
http://66.102.7.104/search?q=cache:Vsb71X4LhC4J:mindprod.com/jgloss/interfacevsabstract.html+when+do+you+use+a+java+interface&hl=tl&gl=ph&ct=clnk&cd=1&client=firefox-a
http://forum.java.sun.com/thread.jspa?threadID=735991&messageID=4229194
Interface vs Abstract Class
http://66.102.7.104/search?q=cache:Vsb71X4LhC4J:mindprod.com/jgloss/interfacevsabstract.html+when+do+you+use+a+java+interface&hl=tl&gl=ph&ct=clnk&cd=1&client=firefox-a
Thursday, October 26, 2006
Business/Domain Model, Process, Analyst, etc
Taken from: http://iconprocess.com
The Business Object Model is a class diagram describing the key business entities and workers (roles) in the business processes being analyzed.
Domain Model
A domain model captures the most important Artifact: Business Entity abstractions (modeled as UML classes) within the context of the domain. A domain model does not include any business worker definitions. For example, an insurance company's domain model may include classes and relationships for policy, insured, and claim.
The Role: Business Process Analyst is responsible for Activity: Maintain Business Rules.
The Business Process Analyst needs to be familiar with techniques for organizational design, process improvement, technology assimilation, organizational change, and process modeling. This role must identify opportunities for improving business processes, organizational design, and corporate culture.
The Role: Business Designer performs the Activity: Find Business Workers and Entities, focusing only on the entities.
* The Role: Business Process Analyst and Role: Business Designer use it to capture information about key abstractions in the business, and possibly to describe the business processes in detail.
* The Role: Software Designer uses the model as input to developing analysis and design models, including use case realizations.
* The Role: Requirements Analyst and Role: Information Architect use it as input to the common vocabulary used when defining requirements and developing wireframes, respectively.
* All other roles may use this information to understand the project's key concepts.
The Business Object Model is a class diagram describing the key business entities and workers (roles) in the business processes being analyzed.
Domain Model
A domain model captures the most important Artifact: Business Entity abstractions (modeled as UML classes) within the context of the domain. A domain model does not include any business worker definitions. For example, an insurance company's domain model may include classes and relationships for policy, insured, and claim.
The Role: Business Process Analyst is responsible for Activity: Maintain Business Rules.
The Business Process Analyst needs to be familiar with techniques for organizational design, process improvement, technology assimilation, organizational change, and process modeling. This role must identify opportunities for improving business processes, organizational design, and corporate culture.
The Role: Business Designer performs the Activity: Find Business Workers and Entities, focusing only on the entities.
* The Role: Business Process Analyst and Role: Business Designer use it to capture information about key abstractions in the business, and possibly to describe the business processes in detail.
* The Role: Software Designer uses the model as input to developing analysis and design models, including use case realizations.
* The Role: Requirements Analyst and Role: Information Architect use it as input to the common vocabulary used when defining requirements and developing wireframes, respectively.
* All other roles may use this information to understand the project's key concepts.
Tuesday, October 24, 2006
Monday, October 23, 2006
Sunday, October 22, 2006
PHP and J2EE Links
Php/MySQL Cheat Sheet
http://librenix.com/?inode=7882
Generating Php Code with Elisp
http://librenix.com/?inode=7886
PhP Encryption
http://librenix.com/?inode=9198
Best Practices Coding Style
http://librenix.com/?inode=464
----
Code Testing with JUnit
http://librenix.com/?inode=8473
Apache Geronimo and Spring Framework
http://www-128.ibm.com/developerworks/opensource/edu/os-dw-os-ag-springframe2.html?S_
TACT=105AGX59&S_CMP=GR&ca=dgr-lnxw16GeronimoSpringApp
Eclipse Real-time JVM Analysis
http://librenix.com/?inode=9405
http://librenix.com/?inode=7882
Generating Php Code with Elisp
http://librenix.com/?inode=7886
PhP Encryption
http://librenix.com/?inode=9198
Best Practices Coding Style
http://librenix.com/?inode=464
----
Code Testing with JUnit
http://librenix.com/?inode=8473
Apache Geronimo and Spring Framework
http://www-128.ibm.com/developerworks/opensource/edu/os-dw-os-ag-springframe2.html?S_
TACT=105AGX59&S_CMP=GR&ca=dgr-lnxw16GeronimoSpringApp
Eclipse Real-time JVM Analysis
http://librenix.com/?inode=9405
Wednesday, October 18, 2006
Ahh PHP
Thanks to ATI guys. I discovered that PHP is never sleeping and is not late in the game. If Java follows standards like design patterns, eg. MVC. PHP is quick to adjust and adopt these standards.
For example, CakePHP is a framework for PHP that uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC.
It's manual is at http://manual.cakephp.org/
I also discovered Code Igniter, an open source web application framework. The URL is http://www.codeigniter.com/user_guide
For example, CakePHP is a framework for PHP that uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC.
It's manual is at http://manual.cakephp.org/
I also discovered Code Igniter, an open source web application framework. The URL is http://www.codeigniter.com/user_guide
Tuesday, October 17, 2006
What is a UML Domain Model?
UML domain model will relate objects in the system domain to each other. It will define concepts and terms. Objects in the domain model can be:
- Physical objects
- Abstract concept
Basic thoughts on entrepreneurship
Setting up a company is never an easy thing to do. For one thing, it's not about just providing service or selling products but doing so that brings profits to the company as well. Bringing profits to the company is also not an easy thing for it entails a lot of things. Making sales is not tantamount to profits if other things like costs and expenses are not measured or computed, or liabilities are not looked at side by side assets.
In business, not everything is about finance but also taking time to "measure" non-financial matters such as labor, customer acquisition and retention, lead costs, depreciation, cost of getting and retaining manpower, etc.
A lot has been said about the major shift from being employed where one simply focuses on providing service to the customer(to the employer) at a specified period of time. But the moment one moves from being employed to having a business to run, he then takes bigger roles and responsibilities.
In business, not everything is about finance but also taking time to "measure" non-financial matters such as labor, customer acquisition and retention, lead costs, depreciation, cost of getting and retaining manpower, etc.
A lot has been said about the major shift from being employed where one simply focuses on providing service to the customer(to the employer) at a specified period of time. But the moment one moves from being employed to having a business to run, he then takes bigger roles and responsibilities.
Business Analyst and Systems Analyst
From wikipedia:
A business analyst (BA) is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers.
Common alternate titles are business systems analyst, systems analyst, and functional analyst, although some organizations may differentiate between the above titles and corresponding responsibilities.
Systems analysis' is the science dealing with analysis of complex, large scale systems and the interactions within those systems. This field is closely related to operations research.
A business analyst (BA) is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers.
Common alternate titles are business systems analyst, systems analyst, and functional analyst, although some organizations may differentiate between the above titles and corresponding responsibilities.
Systems analysis' is the science dealing with analysis of complex, large scale systems and the interactions within those systems. This field is closely related to operations research.
Friday, October 13, 2006
Techies and non-techies
There are different kinds of techies that most people are not aware of. The non-techie including our friends, relatives, and casual acquaintances do not have an understanding of the various roles and types of techies. Most often those who do not have an idea have this notion that when someone says he/she works for a computer company (may or may not be a techie) would ask him/her for recommendations regarding the brand or type of computer to buy, or for tips on how to select the best printer or how much the latest LCD monitor is. At other times, when something is wrong with the hardware, like a malfunctioning printer, or system not booting, the techie would be asked for help. I remember a colleague of mine years before who was a senior and technical lead for a software development who didn't know how to operate our company's fax was approached by one of the principals. That friend of mine scratched his head and asked around who among us were familiar with the fax machine.
Not every techie knows about the solution to every kind of computer software and hardware problems. But those who are not techie, don't know that.
Not every techie knows about the solution to every kind of computer software and hardware problems. But those who are not techie, don't know that.
Tuesday, October 10, 2006
What Makes a Good Software Developer?
An article I read recently at Hacknot, titled "Developers are from Mars, Programmers are from Venus” about what it means to be a developer vs. a programmer, raised some interesting discussion points.
The article was rather critical of programmers, who, according to the article, only want to write code, play with new technologies and languages, and consider everything else, an annoying detail that is best avoided as much as possible. Computer programmers, so the article claims, are arrogant, look down on users and intentionally use technical jargon they know will not be understood when they talk to users. Furthermore, they often waste their company’s time and money by engineering overly complex solutions to problems or using non-ideal technologies to solve problems, for no reason other than that it gives them a chance to play with a new language, or technology, or write more complex and interesting code. Developers, on the other hand, care about users and try to explain things to them in terms they can understand, using as little technical jargon as possible, take the time to learn about the problem domain they are working in (accounting, insurance, or whatever), and use the simplest possible solution, even if that solution might not be cool or trendy. In a nutshell, the article claims, "programmers play, developers work”, and goes on to say "it is the developers that you want working in your organization. Programmers are a dime a dozen, but developers can bring real value to a business.”
Whoa. Hold on a second there. First of all, I think it is a huge mistake to try to classify programmers and developers so differently to say that one is from Mars and the other from Venus. In fact, if you talk 20 other developers or programmers, you will probably get 20 different definitions of what the difference is between a developer and a programmer. Why is it so hard to establish a clear distinction? Because in reality, most of us are both developers and programmers.
Many of us started out as programmers. We were interested in programming as an intellectually stimulating pursuit in its own right. What domain we were working in didn’t really matter to us, as long as we were solving problems by writing code. We became developers later on when we got out into the work environment and found out that this kind of work in a typical business environment involved a lot more than just writing code. But in becoming developers, we never abandoned our programmer roots. We still enjoy programming as an intellectual challenge in its own right and enjoy learning new technologies and languages simply because they are something new to learn.
On the other hand, many of us started out as developers. We had a domain specific problem that we needed to solve, and we couldn’t find any existing software to do it, nor could we hire someone else to do it (possibly financial constraints). So we decided we would try to solve it ourselves. We went down to the local bookstore, and picked up a couple of books on programming, and we learned as we went. We were much like any other "do-it-yourselfer” in this respect. Learning programming was a means to an end in order to solve a domain specific problem we needed to solve. However, eventually, we became programmers as well as developers, because we developed a genuine interest in programming as an enjoyable and intellectually stimulating pursuit in its own right. Those of us who didn’t probably didn't become professional software developers. Why? Because software development would not have been an enjoyable activity for us unless we were working on a domain specific problem for which we had a very strong interest. For example, unless we happened to have a passion for the insurance business, we would not have enjoyed working as a software developer for an insurance company, unless we enjoyed the act of programming as an activity in its own right.
So are developers and programmers really that different? Is one from Mars and the other from Venus? I say not at all. And qualities of both developers and programmers are required in order for someone to be good at the task of software development. Is it better to use simpler solutions, even if they are not "cool”? In general, yes. But at the same time, we must be careful that software development does not change from an enjoyable and challenging activity, into a monotonous and tedious task that involves nothing more than dragging and dropping prefabricated pieces onto a canvas to create "plug and play” software. People who enjoy their work are more productive than those who do not. Because of this a pure developer, who is forced to work in problem domains he or she is not particularly interested in, using only the simplest possible solutions which require the least effort to implement, may actually be less productive than a programmer who implements a more complex solution, but enjoys programming as a challenging activity in its own right, even if they are not particularly interested in the problem domain.
I am reminded of a quote from one of the prominent pioneers in our field:
"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.” -- Alan Jay Perlis (April 1, 1922 - February 7, 1990)
Kind Regards,
Mike Urban
murban@javalobby.org
The article was rather critical of programmers, who, according to the article, only want to write code, play with new technologies and languages, and consider everything else, an annoying detail that is best avoided as much as possible. Computer programmers, so the article claims, are arrogant, look down on users and intentionally use technical jargon they know will not be understood when they talk to users. Furthermore, they often waste their company’s time and money by engineering overly complex solutions to problems or using non-ideal technologies to solve problems, for no reason other than that it gives them a chance to play with a new language, or technology, or write more complex and interesting code. Developers, on the other hand, care about users and try to explain things to them in terms they can understand, using as little technical jargon as possible, take the time to learn about the problem domain they are working in (accounting, insurance, or whatever), and use the simplest possible solution, even if that solution might not be cool or trendy. In a nutshell, the article claims, "programmers play, developers work”, and goes on to say "it is the developers that you want working in your organization. Programmers are a dime a dozen, but developers can bring real value to a business.”
Whoa. Hold on a second there. First of all, I think it is a huge mistake to try to classify programmers and developers so differently to say that one is from Mars and the other from Venus. In fact, if you talk 20 other developers or programmers, you will probably get 20 different definitions of what the difference is between a developer and a programmer. Why is it so hard to establish a clear distinction? Because in reality, most of us are both developers and programmers.
Many of us started out as programmers. We were interested in programming as an intellectually stimulating pursuit in its own right. What domain we were working in didn’t really matter to us, as long as we were solving problems by writing code. We became developers later on when we got out into the work environment and found out that this kind of work in a typical business environment involved a lot more than just writing code. But in becoming developers, we never abandoned our programmer roots. We still enjoy programming as an intellectual challenge in its own right and enjoy learning new technologies and languages simply because they are something new to learn.
On the other hand, many of us started out as developers. We had a domain specific problem that we needed to solve, and we couldn’t find any existing software to do it, nor could we hire someone else to do it (possibly financial constraints). So we decided we would try to solve it ourselves. We went down to the local bookstore, and picked up a couple of books on programming, and we learned as we went. We were much like any other "do-it-yourselfer” in this respect. Learning programming was a means to an end in order to solve a domain specific problem we needed to solve. However, eventually, we became programmers as well as developers, because we developed a genuine interest in programming as an enjoyable and intellectually stimulating pursuit in its own right. Those of us who didn’t probably didn't become professional software developers. Why? Because software development would not have been an enjoyable activity for us unless we were working on a domain specific problem for which we had a very strong interest. For example, unless we happened to have a passion for the insurance business, we would not have enjoyed working as a software developer for an insurance company, unless we enjoyed the act of programming as an activity in its own right.
So are developers and programmers really that different? Is one from Mars and the other from Venus? I say not at all. And qualities of both developers and programmers are required in order for someone to be good at the task of software development. Is it better to use simpler solutions, even if they are not "cool”? In general, yes. But at the same time, we must be careful that software development does not change from an enjoyable and challenging activity, into a monotonous and tedious task that involves nothing more than dragging and dropping prefabricated pieces onto a canvas to create "plug and play” software. People who enjoy their work are more productive than those who do not. Because of this a pure developer, who is forced to work in problem domains he or she is not particularly interested in, using only the simplest possible solutions which require the least effort to implement, may actually be less productive than a programmer who implements a more complex solution, but enjoys programming as a challenging activity in its own right, even if they are not particularly interested in the problem domain.
I am reminded of a quote from one of the prominent pioneers in our field:
"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.” -- Alan Jay Perlis (April 1, 1922 - February 7, 1990)
Kind Regards,
Mike Urban
murban@javalobby.org
Monday, October 09, 2006
C and I, with OOAD
I've never had an exhilarating and enlightening a talk as I had with C, a colleague, a friend, a former officemate of mine who is now the founder-CEO of the Philippine's premier training and consultancy for Java, with whom I had a chance to sit down and talk over the weekend.
C and I met for a possible partnership by inviting me to be one of the resources for his startup, which I gladly accepted.
Anyway, on the technical side. He brought to mind and made it clear to me the distinction between applying (or imposing) OOAD (Object-Oriented Analysis and Design) methodology for enterprise Java systems/apps development. As I have been espousing for quite some time that Java people should be practitioners of OOAD (if they have not been doing that) as OOAD enforces (you guess it right) object-oriented thinking, as opposed to "function(or method) thinkers" practiced by the school of Oracle developers where most of the logic are done in stored procs, pl/sql statements, etc.
However, C reminded me about time to market as an important (and deciding) criteria for an Enterprise Client, which in most probability, looks for quick, easy and visible results. The solution provider then takes to mind that "fast delivery of a working system" is the main key factor for his success, and for a greater chance of having repeat customers or the security of future projects. Thus on the business side, it pays very much to consider the "business criteria" rather than the "technical criteria".
I think C and I, as we went along ranting about OOAD, pros and cons, shared and agreed that
as far as business is concerned, OOAD is not something a solutions provider imposes, but rather
something that his client requires. Therefore, the solution provider must consider best-practices along with "business-success (best) practices".
C has a more introspective take on the subject in his blog
C and I met for a possible partnership by inviting me to be one of the resources for his startup, which I gladly accepted.
Anyway, on the technical side. He brought to mind and made it clear to me the distinction between applying (or imposing) OOAD (Object-Oriented Analysis and Design) methodology for enterprise Java systems/apps development. As I have been espousing for quite some time that Java people should be practitioners of OOAD (if they have not been doing that) as OOAD enforces (you guess it right) object-oriented thinking, as opposed to "function(or method) thinkers" practiced by the school of Oracle developers where most of the logic are done in stored procs, pl/sql statements, etc.
However, C reminded me about time to market as an important (and deciding) criteria for an Enterprise Client, which in most probability, looks for quick, easy and visible results. The solution provider then takes to mind that "fast delivery of a working system" is the main key factor for his success, and for a greater chance of having repeat customers or the security of future projects. Thus on the business side, it pays very much to consider the "business criteria" rather than the "technical criteria".
I think C and I, as we went along ranting about OOAD, pros and cons, shared and agreed that
as far as business is concerned, OOAD is not something a solutions provider imposes, but rather
something that his client requires. Therefore, the solution provider must consider best-practices along with "business-success (best) practices".
C has a more introspective take on the subject in his blog
Subscribe to:
Posts (Atom)