Hi!
So this is Christmas...
the time of the year when we basically forget about our computers and focus on the important things in life... eating yourself sick with your whole family.
No Christmas would be complete without a good selection of seasonal music that accompanies us every year, here is my favourites on the subject:
1. John Lennon - so this is Christmas
This song brings back old memories of one of my first Christmases I can remember (surely because the song has about 30 years).
2. Wham! - Last Christmas
A nemesis of polish radio for the past 10 years. Just no holidays without it.
3. Bobby Caldwell & Vanessa Williams - Baby It's Cold Outside
Song written in 1944 by Frank Loesser though the years had a lot of great interpretations but my favorite one is from the '96 Vanessa Williams album - Star Bright. BTW she is a very beautiful woman ;)
4. Skaldowie - z kopyta kulig rwie
This is a polish song from 1968 so you probably wouldn't understand much, but the main theme here is a sleigh ride through the forest (you can find some places that still do it by horse).
5. Chris Rea - Driving Home for Christmas
This list isn't in any particular order because my private Christmas "experience" starts with listening to this song while driving in a snowy, icy road through the forest. The best song ever!
6. Mariah Carey - All I want for Christmas is You
Very warm song performed by the pop diva brings up very warm feelings for sure. This will worm us up in those long and lustrous winters to come.
7. Kenny Rogers & Dolly Parton - Winter Wonderland
Some might say it is a bit corny, in my opinion its a beautiful song that has a lot of positive energy, plus the young Dolly Parton was surely something warming up to look at ;)
Well folks, this concludes my list, feel free to add suggestions to the list,
Have a quiet holiday with your families.
Peter
Saturday, December 25, 2010
Saturday, December 18, 2010
Control authentication with KeePass and Dropbox
Hi!
A few weeks ago it's been brought to my attention that may people have problem with dealing with password sharing and access control of may resources at the same time.
Imagine you have a team consisting of:
- system admins
- programmers
- marketers
Every position requires a different set of passwords, usually there is a lot of passwords (20+) that for security reasons should not be the same text.
I've actually came across a nice, free and fast resolution for the problem.
KeePass (and for Linux KeePassX) is a free password database that can help put in situations like that.
Your team just has to remember the password to the KeePass database. Every access type, or even person can have it's own database, but there emerges a problem of password versioning. Every change of every password would trigger and endless wave of emails to your employees about the changes. Actually there is a neat resolution for the problem as well.
DropBox is a great network service which i love to use. It makes sharing files between my computers at work and home really easy. No more sending yourself emails with files, just drop something to your dropbox folder on one end, and it automatically updates everywhere.
The idea for sharing with dropbox is that you need to create a "company dropbox" account, that everyone is connected to. Every time you or anybody else updates a file everyone that needs to know about the changes uses another password.
Lets summarize what are the benefits here:
- passwords that don't need to be remembered can be very long and complicated (KeePass has a pass generator too)
- an employee has to remember:
1) Dropbox account and password, that's two
2) Keepass db password, that's one
So only three passwords to remember, plus one per every database the employee has access to.
- passwords are automatically updated across our business
- passwords are pretty safe, keepass encrypts with a 256-bit AES or a 256-bit Twofish algorithm that are considered to be very secure by the cryptographic community
Drawbacks:
- every time someone quite their job, you need to change all their passwords + the drobbox password. Changing all passwords actually isn't that much of a problem, since dropbox + keepass resolves it.
- there is limited possibility to create passwords per employee
After this short summary IMHO this is an easy and secure way to share your passwords (or just keep your passwords at bay) without any serious knowledge about security. You may want to check out the keepass plug-in page for additional functionality http://keepass.info/plugins.html
Thanks, and see you next time,
Peter
A few weeks ago it's been brought to my attention that may people have problem with dealing with password sharing and access control of may resources at the same time.
Imagine you have a team consisting of:
- system admins
- programmers
- marketers
Every position requires a different set of passwords, usually there is a lot of passwords (20+) that for security reasons should not be the same text.
I've actually came across a nice, free and fast resolution for the problem.
KeePass (and for Linux KeePassX) is a free password database that can help put in situations like that.
Your team just has to remember the password to the KeePass database. Every access type, or even person can have it's own database, but there emerges a problem of password versioning. Every change of every password would trigger and endless wave of emails to your employees about the changes. Actually there is a neat resolution for the problem as well.
DropBox is a great network service which i love to use. It makes sharing files between my computers at work and home really easy. No more sending yourself emails with files, just drop something to your dropbox folder on one end, and it automatically updates everywhere.
The idea for sharing with dropbox is that you need to create a "company dropbox" account, that everyone is connected to. Every time you or anybody else updates a file everyone that needs to know about the changes uses another password.
Lets summarize what are the benefits here:
- passwords that don't need to be remembered can be very long and complicated (KeePass has a pass generator too)
- an employee has to remember:
1) Dropbox account and password, that's two
2) Keepass db password, that's one
So only three passwords to remember, plus one per every database the employee has access to.
- passwords are automatically updated across our business
- passwords are pretty safe, keepass encrypts with a 256-bit AES or a 256-bit Twofish algorithm that are considered to be very secure by the cryptographic community
Drawbacks:
- every time someone quite their job, you need to change all their passwords + the drobbox password. Changing all passwords actually isn't that much of a problem, since dropbox + keepass resolves it.
- there is limited possibility to create passwords per employee
After this short summary IMHO this is an easy and secure way to share your passwords (or just keep your passwords at bay) without any serious knowledge about security. You may want to check out the keepass plug-in page for additional functionality http://keepass.info/plugins.html
Thanks, and see you next time,
Peter
Friday, December 17, 2010
Multiple repositories in one with svn:externals
Hi there!
Recently I had a problem with my services:
- I had 2 separate websites that use a kind of token authorization system
- I had a lot of code that was used in both web services
Of course the only smart thing to do when you have a sender and receiver on both ends is that its performed by the exactly same code as follows:
Sender service:
$token = new Token();
echo $token->generateToken();
Receiver service:
$token = new $token($_GET['token']);
echo $token->isValid();
So what we need to achieve here is pretty arbitrary to the point I'm making. Just a simple sending and receiving of some token that has to be validated on the other side.
The problem is that those two sites are entirely different projects that share some common logic. The mistake people make is to copy the common code between the services in the hope that no one will change it, or when changed, someone will change it on both ends. There is a lot of room for mistakes here.
Luckily we have svn:externals to help us with the whole process. What we want to achieve can be summarized in a few simple steps:
1) Isolate the common code in another repository to protect it from unwanted changes. Let's say we will name the repository CORE.
2) Remove the obsolete code from all code base in which i was present.
3) Add a external checkout to our library folder:
>svn propget svn:externals library
core https://svn.example.com/core
What this will do is when someone updates the library folder, svn will know to get the external items from the common code repository.
In this example you will have to commit your code to the external repository, but an easier way is that you create a directory for the code in one repository and add a directory externally to another repository that requires the code.
Hope you will take something from this simple example,
see you next time ;)
Peter
Recently I had a problem with my services:
- I had 2 separate websites that use a kind of token authorization system
- I had a lot of code that was used in both web services
Of course the only smart thing to do when you have a sender and receiver on both ends is that its performed by the exactly same code as follows:
Sender service:
$token = new Token();
echo $token->generateToken();
Receiver service:
$token = new $token($_GET['token']);
echo $token->isValid();
So what we need to achieve here is pretty arbitrary to the point I'm making. Just a simple sending and receiving of some token that has to be validated on the other side.
The problem is that those two sites are entirely different projects that share some common logic. The mistake people make is to copy the common code between the services in the hope that no one will change it, or when changed, someone will change it on both ends. There is a lot of room for mistakes here.
Luckily we have svn:externals to help us with the whole process. What we want to achieve can be summarized in a few simple steps:
1) Isolate the common code in another repository to protect it from unwanted changes. Let's say we will name the repository CORE.
2) Remove the obsolete code from all code base in which i was present.
3) Add a external checkout to our library folder:
>svn propget svn:externals library
core https://svn.example.com/core
What this will do is when someone updates the library folder, svn will know to get the external items from the common code repository.
In this example you will have to commit your code to the external repository, but an easier way is that you create a directory for the code in one repository and add a directory externally to another repository that requires the code.
Hope you will take something from this simple example,
see you next time ;)
Peter
Wednesday, December 8, 2010
Starting your own IT business? A few lessons to be learned.
Hi!
The thing is I decided to start My own business (http://fasttrack.pl but it isn't much to look at, still working on it), producing software and websites of course. After some three weeks of muddling through the polish law system I finally managed to start it officially :)
After a few months I have some things I want to talk about that may help you in your endeavor.
Aside from all problems, the first assignment (damkorepetycje.pl), a small co repetition system was quite an interesting task. Not only learning (the hard way) that absolutely everything must be perfect up to 1 pixel, but also learned how to employ people. You always have to be in control, if you outsource some project, every few days look at the results, the time/hour costs.
Lesson one:
Always have a written contract with the functionality annexed to it.
Even if someone won't pay you, you still have a chance of getting back the costs.
It's an industry standard so you won't have any problem finding templates on the web.
Lesson two:
Include the first changes (except obvious bugs) in the price, for next changes bill your client separately.
As a young business you lack credibility. The clients are unsure if you won't run and leave them with the problems on the website. If you decide to include project maintenance over an year or so in the project you might get bigger projects.
Lesson three:
If you work with someone, keep track of the work being done.
If you leave everything to your employee/subcontractor there is a big possibility that the client won't get what he/she ordered or anything at all. Every few days have your employees (programmers) show you whet is accomplished and what is still on the to do list. Tell them what has the highest priority for the client. I personally use Redmine to track progress, keep in touch with clients (although there are better tools for that out there), bug tracking and calculate bills (from spent time).
If you're looking for something more sophisticated, actually JIRA has some event where they give you a starter package for 10 users for $10 so its really cheap (for some charity I think).
Lesson three:
Don't ask people to work for you, let them ask, just be in the right place.
Over time I've worked with many of my colleagues that were working with me for some time. Really bib disappointment, pretty much nothing was done right. I've learned to let people look form me, not the other way. Some of the best employees were hired from some small cities university IT forum. The main thought here is - look for people in niches not on php.com or something like that. You wont get someone that is very much skilled but they sure are motivated and in my opinion that's the key to success.
I only hope that the lessons I had to learn the hard way will be of some use to you, my Dear Readers :)
See you soon.
Peter
The thing is I decided to start My own business (http://fasttrack.pl but it isn't much to look at, still working on it), producing software and websites of course. After some three weeks of muddling through the polish law system I finally managed to start it officially :)
After a few months I have some things I want to talk about that may help you in your endeavor.
Aside from all problems, the first assignment (damkorepetycje.pl), a small co repetition system was quite an interesting task. Not only learning (the hard way) that absolutely everything must be perfect up to 1 pixel, but also learned how to employ people. You always have to be in control, if you outsource some project, every few days look at the results, the time/hour costs.
Lesson one:
Always have a written contract with the functionality annexed to it.
Even if someone won't pay you, you still have a chance of getting back the costs.
It's an industry standard so you won't have any problem finding templates on the web.
Lesson two:
Include the first changes (except obvious bugs) in the price, for next changes bill your client separately.
As a young business you lack credibility. The clients are unsure if you won't run and leave them with the problems on the website. If you decide to include project maintenance over an year or so in the project you might get bigger projects.
Lesson three:
If you work with someone, keep track of the work being done.
If you leave everything to your employee/subcontractor there is a big possibility that the client won't get what he/she ordered or anything at all. Every few days have your employees (programmers) show you whet is accomplished and what is still on the to do list. Tell them what has the highest priority for the client. I personally use Redmine to track progress, keep in touch with clients (although there are better tools for that out there), bug tracking and calculate bills (from spent time).
If you're looking for something more sophisticated, actually JIRA has some event where they give you a starter package for 10 users for $10 so its really cheap (for some charity I think).
Lesson three:
Don't ask people to work for you, let them ask, just be in the right place.
Over time I've worked with many of my colleagues that were working with me for some time. Really bib disappointment, pretty much nothing was done right. I've learned to let people look form me, not the other way. Some of the best employees were hired from some small cities university IT forum. The main thought here is - look for people in niches not on php.com or something like that. You wont get someone that is very much skilled but they sure are motivated and in my opinion that's the key to success.
I only hope that the lessons I had to learn the hard way will be of some use to you, my Dear Readers :)
See you soon.
Peter
Subscribe to:
Posts (Atom)