One thing I really hate is having to use collection types in my java code. Whenever this takes place I have to jump back to the JDK documentation and start digging for methods.
Suddenly, I decided to put an end to this fuss (sorry 3akilmit fuss). I searched google for a simple tutorial, and guess what I found. A wonderfully illustrated simple to use up-to-date small tutorial PDF document, check it out here.
Wonderful and easily digestible by an average mind.
Wednesday, January 31, 2007
Tuesday, January 30, 2007
Purchasing A Laptop
I've learned two things when buying laptops:
1. Research well, do your own study and dont take an impulsive decision. A laptop will stay with you for at least two years, and it will affect your convenience in life throughout this period.
2. The last thing to look at is the specs posted in the laptops offer.
Here are what I first ask about, and I'll also tell you about my preferences:
1. Brand. Its either HP, IBM, Toshiba, Sony VIAO, Dell, or an uncommon brand with a cheap price. My golden rule here is.. dont base your judgement on a brand! Even within the same brand, every model has its differences from other models, its defects, inconveniences, advantages, etc. So, dont compare an IBM to an HP, but rather compare IBM Thinkpad XXX to HP nx83xx (example), or even compare HP nx7400 to HP nx8300. You can ofcourse compare support for these brands based on your location.
My favorite brand though is HP, why I dont know I just love it.
2. Series. Always go for the Professional (or Business) series, forget the Home or Multimedia series, unless you're the family guy. Actually I hate HP's home/multimedia series. What really makes me tick is their Professional series.
3. Screen Resolution. One of the things I hate about laptop offers is that they HARDLY EVER mention the screen resolution. The best resolution to go for is 1280 x 800, nothing more, nothing less. Forget about 1024 x 768, and some new high resolutions really make your eyes burden. If you're attracted to high resolutions, then dont go for more than 1400x1050.
4. Screen Type. Its either TFT, Bright View, or LCD. I prefer Bright View. TFT will get dark by time due to the burning of the TFT cells. Some disadvantages of TFT and LCD is that they become a white screen from a bent angle, some new TFT technologies remedy this problem. And by the way, I've seen companies and people soliciting this problem as a privacy feature. For example, when ur in an internet cafe, people wont see what you're working on from a bent angle. Bright View is very new; it comes by different names, XBRITE for Sony, Bright View for HP, TrueBrite for Toshiba (as far as I can remember). The funny thing is NONE of these companies manufacture these screens, they buy it from a third party and sell it under different names. This really surprised me, specially from SONY.
Some people that tried Bright View at first (specially those used to TFT/LCD) felt that its weird and causes a headache. But trust me, this is only the first week, you'll get used to it, and its also more safer than TFT screens for your eyes.
For me, bright view is the best and it will maintain its quality through the laptop's life time.
5. The sound speakers. Try them out, try a song with a strong base sound and popup the volumne to the max, if you can here rambling inside the speakers, then skip this laptop. This happened to me with the SONY VAIO and some Home Series HP. Also, try to get the laptop where the speakers are on the prolonged edges of the keyboard, or on the front, and do the BASE TEST. Dont let the sales man put for you a Birdy Song while smiling at you.
6. The USB locations. You need two on the left, one on the right, two on the back, or else you'll be leading an inconveninent life. Have the USB ports arranged like that '_ _' and not '=', This is becoz some flash memory sticks will be thick to stumble any extra USB device on the adjacent port.
7. Heat Dissipation. You need good ventilation. There will be heat, but you dont want this heat to be coming out from the Keyboard, or from the left or right bottom corners of the keyboard, or else they will hurt your hand palms really bad.
8. Hard Disk Location. Should be anywhere other than under your mouse touchpad panel. You're bottom palm is heavier than you think and could one day affect your hard disk (happened to FUJITSU SEIMENS users which totally corrupted the hard disk).
9. RAM. For 512, they will write 512MB or 512MB DDR2 in the offer. Ask about the bus speed, and dont go less than 633MHz RAM Bus Speed.
10. Do you want XP Pro, or XP Home. If you dont, then try to find a laptop without them, you'll save about a $100 dollars in price.
11. Mouse, touch pad or rubber? I dont care, I always use an external small mouse. If you care about that then make sure to know what you want.
12. Check the price on the company's website, see a demo, for the model you want, check next and previous item in the same series. For example, my laptop HP nx7400, I checked nx8* and nx6* to see the differences.
13. Try out the keyboard. Make sure to try it out and feel comfortable with it.
14. CD/DVD Writers/Reader. Dont go for less, let it be full writing and reading for DVDs and CDs.
15. Check the microsoft key button, I love this button. "Microsoft Key + D" Minimizes the whole desktop or returns it to its previous state. Really useful.
16. Wifi & Bluetooth. Check that two buttons exist that allow you to disable/enable Wifi or disable/enable bluetooth.
Thats all I can think of.
HP nx7400 for me was super excellent.
ps. I'm a programmer, so keep this in mind.
1. Research well, do your own study and dont take an impulsive decision. A laptop will stay with you for at least two years, and it will affect your convenience in life throughout this period.
2. The last thing to look at is the specs posted in the laptops offer.
Here are what I first ask about, and I'll also tell you about my preferences:
1. Brand. Its either HP, IBM, Toshiba, Sony VIAO, Dell, or an uncommon brand with a cheap price. My golden rule here is.. dont base your judgement on a brand! Even within the same brand, every model has its differences from other models, its defects, inconveniences, advantages, etc. So, dont compare an IBM to an HP, but rather compare IBM Thinkpad XXX to HP nx83xx (example), or even compare HP nx7400 to HP nx8300. You can ofcourse compare support for these brands based on your location.
My favorite brand though is HP, why I dont know I just love it.
2. Series. Always go for the Professional (or Business) series, forget the Home or Multimedia series, unless you're the family guy. Actually I hate HP's home/multimedia series. What really makes me tick is their Professional series.
3. Screen Resolution. One of the things I hate about laptop offers is that they HARDLY EVER mention the screen resolution. The best resolution to go for is 1280 x 800, nothing more, nothing less. Forget about 1024 x 768, and some new high resolutions really make your eyes burden. If you're attracted to high resolutions, then dont go for more than 1400x1050.
4. Screen Type. Its either TFT, Bright View, or LCD. I prefer Bright View. TFT will get dark by time due to the burning of the TFT cells. Some disadvantages of TFT and LCD is that they become a white screen from a bent angle, some new TFT technologies remedy this problem. And by the way, I've seen companies and people soliciting this problem as a privacy feature. For example, when ur in an internet cafe, people wont see what you're working on from a bent angle. Bright View is very new; it comes by different names, XBRITE for Sony, Bright View for HP, TrueBrite for Toshiba (as far as I can remember). The funny thing is NONE of these companies manufacture these screens, they buy it from a third party and sell it under different names. This really surprised me, specially from SONY.
Some people that tried Bright View at first (specially those used to TFT/LCD) felt that its weird and causes a headache. But trust me, this is only the first week, you'll get used to it, and its also more safer than TFT screens for your eyes.
For me, bright view is the best and it will maintain its quality through the laptop's life time.
5. The sound speakers. Try them out, try a song with a strong base sound and popup the volumne to the max, if you can here rambling inside the speakers, then skip this laptop. This happened to me with the SONY VAIO and some Home Series HP. Also, try to get the laptop where the speakers are on the prolonged edges of the keyboard, or on the front, and do the BASE TEST. Dont let the sales man put for you a Birdy Song while smiling at you.
6. The USB locations. You need two on the left, one on the right, two on the back, or else you'll be leading an inconveninent life. Have the USB ports arranged like that '_ _' and not '=', This is becoz some flash memory sticks will be thick to stumble any extra USB device on the adjacent port.
7. Heat Dissipation. You need good ventilation. There will be heat, but you dont want this heat to be coming out from the Keyboard, or from the left or right bottom corners of the keyboard, or else they will hurt your hand palms really bad.
8. Hard Disk Location. Should be anywhere other than under your mouse touchpad panel. You're bottom palm is heavier than you think and could one day affect your hard disk (happened to FUJITSU SEIMENS users which totally corrupted the hard disk).
9. RAM. For 512, they will write 512MB or 512MB DDR2 in the offer. Ask about the bus speed, and dont go less than 633MHz RAM Bus Speed.
10. Do you want XP Pro, or XP Home. If you dont, then try to find a laptop without them, you'll save about a $100 dollars in price.
11. Mouse, touch pad or rubber? I dont care, I always use an external small mouse. If you care about that then make sure to know what you want.
12. Check the price on the company's website, see a demo, for the model you want, check next and previous item in the same series. For example, my laptop HP nx7400, I checked nx8* and nx6* to see the differences.
13. Try out the keyboard. Make sure to try it out and feel comfortable with it.
14. CD/DVD Writers/Reader. Dont go for less, let it be full writing and reading for DVDs and CDs.
15. Check the microsoft key button, I love this button. "Microsoft Key + D" Minimizes the whole desktop or returns it to its previous state. Really useful.
16. Wifi & Bluetooth. Check that two buttons exist that allow you to disable/enable Wifi or disable/enable bluetooth.
Thats all I can think of.
HP nx7400 for me was super excellent.
ps. I'm a programmer, so keep this in mind.
Monday, January 29, 2007
Say Hi to Derby.
MySQL, Postgres and now Derby... a new database that adds up to the competition. This time from IBM directly to the opensource community and under the wonderful Apache License.
Now this database is amazingly amazing, it supports transactions, its java based, it has a small footprint (2 Megabytes), it supports full encryption storage, it supports multiple access methods including SQL and low level API calls.
What I like about Derby the most is that it started as a commercial database (known as IBM Cloudscape) and then got released to opensource. This guarantees the best of both worlds; a commercial quality database with full opensource transparency and community support.
My only problem with projects that start as opensource is that you rarely find quality efforts put into them unless they are being sponsored by a big company or are provided with donations.
On the other hand, commercial products, if not thriving for quality, they risk a chance of losing their competition and their business. Not only quality software, but quality documentation and quality support and quality *. With a lot of exceptions here and there, I still believe that commercial products have a greater probability of meeting high quality standards.
Now this database is amazingly amazing, it supports transactions, its java based, it has a small footprint (2 Megabytes), it supports full encryption storage, it supports multiple access methods including SQL and low level API calls.
What I like about Derby the most is that it started as a commercial database (known as IBM Cloudscape) and then got released to opensource. This guarantees the best of both worlds; a commercial quality database with full opensource transparency and community support.
My only problem with projects that start as opensource is that you rarely find quality efforts put into them unless they are being sponsored by a big company or are provided with donations.
On the other hand, commercial products, if not thriving for quality, they risk a chance of losing their competition and their business. Not only quality software, but quality documentation and quality support and quality *. With a lot of exceptions here and there, I still believe that commercial products have a greater probability of meeting high quality standards.
Thursday, January 25, 2007
Role Based Security
Just a quick summary from the last security post...
A resource is what you need to protect. It could be a document, html page, folder, part of the system, etc.
A subject is the user, him or her who acts on the resource.
An action is what the subject performs on a resource.
An Access List is a table describing what 'action'(s) can a subject perform on a resource.
Lets say we have an admin application, with four sections. User Management, Reporting, Backup & Restore. These can be 3 resources that we want to protect. Remember, a 'resource' is any thing you want to restrict access to.
The subjects are the 10 users. For simplicity, the actions can be Allow, Deny. (ofcourse, some actions could apply to certain resources only specially when you have finer permissions).
The access list could contain:
User A --> Allow --> User Management
User A --> Allow --> Backup & Restore
User A --> Allow --> Reporting
User C --> Allow --> Reporting
User C --> Allow --> Backup & Restore
User C --> Deny --> User Management
User D --> Allow --> Reporting
...
For 10 users, the table grows, for 100 users the Access List becomes so big... and so administratively consuming. The poor administrator will have to assign the action for every and each user on the system.
Here comes the concept of the "Role". A role is simple a middle entity between the subject's (ie. users) and the actions that would greatly simplify maintaing the access list. The access list in role-based security is called a Role Based Access Control List (abbr. RBACL).
We can now create three Roles; Reporter, Full User, and Guest. The Role Based Access List will now hold Role --> Action --> Resource instead of User --> Action --> Resource.
And another table will hold the User --> Role mapping.
See how simple the Access List becomes:
Full User --> Allow --> User Management
Full User --> Allow --> Reporting
Full User --> Allow --> Backup & Recovery
Reporter --> Allow --> Reporting
Reporter --> Deny --> User Management
Reported --> Deny --> Backup & Recovery
Guest --> Deny --> Backup & Recovery
Guest --> Deny --> Reporting
Guest --> Deny --> User Management
Thats it! Now all you have to do is to add a column in the users table
to specify a Role.
for example, User --> Roles will be:
User A --> Full User
User D --> Guest
User E --> Reporter
User F --> Guest
See how simple it becomes, every new user will only need to assign him or her one Role instead of re-defining all the actions he can perform.
Next post, I'll introduce you to extending your design, and some guidelines to stick to.
A resource is what you need to protect. It could be a document, html page, folder, part of the system, etc.
A subject is the user, him or her who acts on the resource.
An action is what the subject performs on a resource.
An Access List is a table describing what 'action'(s) can a subject perform on a resource.
Lets say we have an admin application, with four sections. User Management, Reporting, Backup & Restore. These can be 3 resources that we want to protect. Remember, a 'resource' is any thing you want to restrict access to.
The subjects are the 10 users. For simplicity, the actions can be Allow, Deny. (ofcourse, some actions could apply to certain resources only specially when you have finer permissions).
The access list could contain:
User A --> Allow --> User Management
User A --> Allow --> Backup & Restore
User A --> Allow --> Reporting
User C --> Allow --> Reporting
User C --> Allow --> Backup & Restore
User C --> Deny --> User Management
User D --> Allow --> Reporting
...
For 10 users, the table grows, for 100 users the Access List becomes so big... and so administratively consuming. The poor administrator will have to assign the action for every and each user on the system.
Here comes the concept of the "Role". A role is simple a middle entity between the subject's (ie. users) and the actions that would greatly simplify maintaing the access list. The access list in role-based security is called a Role Based Access Control List (abbr. RBACL).
We can now create three Roles; Reporter, Full User, and Guest. The Role Based Access List will now hold Role --> Action --> Resource instead of User --> Action --> Resource.
And another table will hold the User --> Role mapping.
See how simple the Access List becomes:
Full User --> Allow --> User Management
Full User --> Allow --> Reporting
Full User --> Allow --> Backup & Recovery
Reporter --> Allow --> Reporting
Reporter --> Deny --> User Management
Reported --> Deny --> Backup & Recovery
Guest --> Deny --> Backup & Recovery
Guest --> Deny --> Reporting
Guest --> Deny --> User Management
Thats it! Now all you have to do is to add a column in the users table
to specify a Role.
for example, User --> Roles will be:
User A --> Full User
User D --> Guest
User E --> Reporter
User F --> Guest
See how simple it becomes, every new user will only need to assign him or her one Role instead of re-defining all the actions he can perform.
Next post, I'll introduce you to extending your design, and some guidelines to stick to.
Tuesday, January 23, 2007
Goodbye PHP. With Love, Basil.
I dropped PHP, in favor of wonderful JSP. Yes, yes and yes. After too many thoughts, and too many oooofss, its time my friend to start from the end.
Frankly speaking, I have about a thousand reasons why I dropped PHP. Half of them arise from the -ve's (negatives) of the PHP language, and the rest comes from the +ve's of the Java language and the wonderful Java programming mindset.
I wont name them here, you can call me on skype to discuss this if you like. But, I dont even have the time to complain about PHP in this blog. We had good times together, but at the end, leaving this language (from my perspective) is a mindful correct decision. The decision is not a religious one, I might still 'have' to use it in several occasions eg. quick small web-apps, hosting code, scripts, and current codebases.
Frankly speaking, I have about a thousand reasons why I dropped PHP. Half of them arise from the -ve's (negatives) of the PHP language, and the rest comes from the +ve's of the Java language and the wonderful Java programming mindset.
I wont name them here, you can call me on skype to discuss this if you like. But, I dont even have the time to complain about PHP in this blog. We had good times together, but at the end, leaving this language (from my perspective) is a mindful correct decision. The decision is not a religious one, I might still 'have' to use it in several occasions eg. quick small web-apps, hosting code, scripts, and current codebases.
Saturday, January 20, 2007
Guidelines on Designing a Better Security Model
I've collected some quick notes that will be helpful to guide you in designing a better security model. And to make it simpler, I'll explain it in a step by step example.
Assume you designed/implemented a multi-user application and would like to implement some sort of manageable security for the login accounts on the system. Read the following scenario:
1. Your system is comprised from a set of documents and pages.
2. You have multiple users on your system that can login.
3. The different users can perform different actions on the different documents and pages.
Till here we need to take a break and define some standard terminology used all over.
When it comes to security, the documents and pages are termed "resources", the different users are termed "subjects" and the different actions performed from those "subjects" on these "resources" are termed "actions".
4. I'd like now to collect a list of all the resources, actions and users on my application before I step into any design issues.
5. The resources I have are "Documents" and "Pages"
6. The actions I have are "Read", "Read/Write", "Upload", "Delete", "Edit" as an example. Note that certain "actions" can apply to certain "resources", while have no significance for other "resources", for eg. I can "Upload" a "Document", but I cant "Upload" a "Page". This is okay.
7. A list of users, this is usually stored somewhere in a database table or wherever, the important thing here is that those "subjects" are known.
After preparing a list of "resouces", "subjects" and "actions", I'll assume that no security is applied at all in the first place.
This means that any "subject" can perform any "action" on any "resource" whatsoever. In such a system, freedom fighters will enjoy it the most, while the rest will feel very insecure. Serving the rest will need some better security constraints on the different actions and resources in the system (sounds a bit political :\)
Here comes the concept of the "Access List".
The "Access List" simply defines which subjects can perform which actions on which resources?
Database wise, consider it a problem to figure out, simply it could be a table with a user id, resource id and action(s) for each row. Remember, its your design, I'm just giving guidelines here.
Ofcourse, when talking about the resource document or the resource page, we are indicating the resource type, thus its more of a resource type, and not a specific resource. Again, its your design, some might choose a very fine grained security model in which every single document has its own security, others will be comfortable with a certain action applied or denied for all documents.
An example "Access List" will simply say:
Subject "Basil" can "Delete" resource "Documents"
Subject "Basil" can "Read/Write" resource "Pages"
Subject "Whoever" can "Read Only" resource "Documents"
... (and so on)
The problem here is that if I have 100 users on my system, with 8 types of actions and three types of resources, then this "Access List" can grow indefinitely when describing the different permissions and will be hard to maintain by an administrator on the system.
Next post I'll show you how to tackle this problem.
ps. Comments, anybody, please, starting to feel lonely here.
Assume you designed/implemented a multi-user application and would like to implement some sort of manageable security for the login accounts on the system. Read the following scenario:
1. Your system is comprised from a set of documents and pages.
2. You have multiple users on your system that can login.
3. The different users can perform different actions on the different documents and pages.
Till here we need to take a break and define some standard terminology used all over.
When it comes to security, the documents and pages are termed "resources", the different users are termed "subjects" and the different actions performed from those "subjects" on these "resources" are termed "actions".
4. I'd like now to collect a list of all the resources, actions and users on my application before I step into any design issues.
5. The resources I have are "Documents" and "Pages"
6. The actions I have are "Read", "Read/Write", "Upload", "Delete", "Edit" as an example. Note that certain "actions" can apply to certain "resources", while have no significance for other "resources", for eg. I can "Upload" a "Document", but I cant "Upload" a "Page". This is okay.
7. A list of users, this is usually stored somewhere in a database table or wherever, the important thing here is that those "subjects" are known.
After preparing a list of "resouces", "subjects" and "actions", I'll assume that no security is applied at all in the first place.
This means that any "subject" can perform any "action" on any "resource" whatsoever. In such a system, freedom fighters will enjoy it the most, while the rest will feel very insecure. Serving the rest will need some better security constraints on the different actions and resources in the system (sounds a bit political :\)
Here comes the concept of the "Access List".
The "Access List" simply defines which subjects can perform which actions on which resources?
Database wise, consider it a problem to figure out, simply it could be a table with a user id, resource id and action(s) for each row. Remember, its your design, I'm just giving guidelines here.
Ofcourse, when talking about the resource document or the resource page, we are indicating the resource type, thus its more of a resource type, and not a specific resource. Again, its your design, some might choose a very fine grained security model in which every single document has its own security, others will be comfortable with a certain action applied or denied for all documents.
An example "Access List" will simply say:
Subject "Basil" can "Delete" resource "Documents"
Subject "Basil" can "Read/Write" resource "Pages"
Subject "Whoever" can "Read Only" resource "Documents"
... (and so on)
The problem here is that if I have 100 users on my system, with 8 types of actions and three types of resources, then this "Access List" can grow indefinitely when describing the different permissions and will be hard to maintain by an administrator on the system.
Next post I'll show you how to tackle this problem.
ps. Comments, anybody, please, starting to feel lonely here.
Tuesday, January 16, 2007
In search for a good security model
I'm currently researching for some good way of implementing a security model for an administrative application. See, this is one of the areas where you really need a good design. And if not well thought of, then the code can easily get dirty and strangled in one month's time.
In small applications, we used to implement such in a very simple way by using database columns with true/false values or by using a access mask stored in a string.
However, such methodology proves very weak when its times to scale and fine tune your apps security demands. A security model is something that doesn't stay the same since it will be affected by any extra functionalities added to the application in future versions, therefore, as i already said, it is one of the areas that need deep thought and a good design.
If you're not acquainted to the terms: Policy, Subject, Resource, Role Based Access List, Authenticator, Authorizer... then HANDS OFF the security architecture document and delegate it to someone else. I know you have the brain power to do it, but without the correct knowledge, it wont be easy.
In small applications, we used to implement such in a very simple way by using database columns with true/false values or by using a access mask stored in a string.
However, such methodology proves very weak when its times to scale and fine tune your apps security demands. A security model is something that doesn't stay the same since it will be affected by any extra functionalities added to the application in future versions, therefore, as i already said, it is one of the areas that need deep thought and a good design.
If you're not acquainted to the terms: Policy, Subject, Resource, Role Based Access List, Authenticator, Authorizer... then HANDS OFF the security architecture document and delegate it to someone else. I know you have the brain power to do it, but without the correct knowledge, it wont be easy.
Subscribe to:
Posts (Atom)