For mart and everyone else, $@ is populated by eval. So if an error occurs the error message is there. So what he describes would be like this:
sub check {
my $ip = shift;
eval{ &lib::function($ip) };
return !$@;
}
So if $@ is null it returns true. Otherwise false since ! is a condition operator. And they can do false by calling "die" in that lib::function. But yes, that is rather silly. I'm hoping they couldn't control the other code for some reason.:)
It also seems to make people load frameworks rather than learn the language. I've fixed a few libraries I found that were using Moose by removing the framework and replacing it with 30 lines of OO code. They loaded another 35 files just to avoid a couple ISA statements and do some input validation.
If people bothered to learn the language they could make their code even faster and cleaner.
This problem is even worse in PHP. And java seems to require every project to write their own.:/
It's easy to infer data for the most part. The biggest challenge I see to your requirement for keys is the lack of interesting searches. If you encrypt everything and require keys then people won't be able to search to see if they have the same hobbies as you. What you suggest isn't much of a social site but more of a private BBS almost. Only a few can dial-in and the rest of the world knows nothing of the content.
I've got a HostGator, dedicated server in Germany and a 1and1 developer account (for a few years now). I'm in the process of moving them all into VPS at slicehost.com. You can start the slices out cheap and work your way up to multiple slices with backnet and public interfaces. So if you need to grow you can do a load balancer on your primary IP and then have other slices doing the work. Their admin tools are pretty easy to deal with too. This option is best if you aren't afraid to administrate your own box though. They have Chat support, forums, articles etc to help people out who are fairly new to system administration with optional backup for your slices.
I've thought about working with either RSS or pushing.torrent files and then having torrent daemon's synce files for me. But so far that's been overly complicated as I have ~1500 production web servers to keep up to date on different code releases depending on what cluster they're in.
Currently we have a database of our production equipment and we keep track of what cluster/role a server is in. So the boxes all run a cron every minute that checks to see if a new "version" of a release is available (any code change whether a new code release or just an update increments version for that cluster).
Now we're use rsync for our transfer. So we keep our/etc/rsync.conf up to date with the potential subnets that we have internally so random outside machines on the WAN can't rsync to our boxes. But we also keep a "lock" table in our database along with the state of each server.
So we have one super seed if you will which keeps a copy of code for all clusters. When you update a release (kept elsewhere) and then "push" the change you made gets copied to the super seed machine. Once that is done the version gets incremented and then the crons start to look for the new code.
Basic idea to locking we we limit the number of peers a box is allowed to have. So in order to not impact production traffic it's set to 3 currently (plenty fast). So if no "peers" (any machine in the cluster that is not the seed) has the code it will be used first and the boxes that fired off the cron last will sit in a queue (waiting to get a lock on anything with code that hasn't reached it's limit of locks). So when it first starts out the first three boxes will fail over to the super seed. Then the peers will start to get it from those boxes once they are updated.
Doing a code push to our larger cluster used to take 45 minutes to an hour (was done in sequence and not in parallel) but now takes about 5 minutes.
My next goals are to distribute the super seeds and potentially use RPM distribution since I'm working on making the code release only restart the fewest service necessary in order to pick up the changes. And with RPM I can have those commands in the install portion.:)
That just seems like a horrible idea since they just make it so dust will stick to everything. Not to mention having a high frequency circuit shoved into my case which could be leaking RF into the motherboard seems like a horrible idea as well.
So potentially I would have curruption of the signal on the high speed buses of the mobo (runs slower due to error correction) and dust stuck to everything in my computer to where I'd actually have to wipe the surfaces down.
You are being nice by giving them notice. They can't make you stay longer in order to find a replacement. The fact that your boss can't cope with stress isn't your problem.
And in terms of future jobs you can always put down someone else as a reference from the company.
Just don't pee on everything on your way out and you should be fine.:)
You can always try out http://www.slimdevices.com. They do wireless server based music systems. And you can play it in every room or separate streams to each room.
Slashdot Mirror
For mart and everyone else, $@ is populated by eval. So if an error occurs the error message is there. So what he describes would be like this:
:)
sub check {
my $ip = shift;
eval{ &lib::function($ip) };
return !$@;
}
So if $@ is null it returns true. Otherwise false since ! is a condition operator. And they can do false by calling "die" in that lib::function. But yes, that is rather silly. I'm hoping they couldn't control the other code for some reason.
It also seems to make people load frameworks rather than learn the language. I've fixed a few libraries I found that were using Moose by removing the framework and replacing it with 30 lines of OO code. They loaded another 35 files just to avoid a couple ISA statements and do some input validation. If people bothered to learn the language they could make their code even faster and cleaner. This problem is even worse in PHP. And java seems to require every project to write their own. :/
I'm sure CSI could show us what was there... they can even show us encrypted IPs! ENHANCE!!
It's easy to infer data for the most part. The biggest challenge I see to your requirement for keys is the lack of interesting searches. If you encrypt everything and require keys then people won't be able to search to see if they have the same hobbies as you. What you suggest isn't much of a social site but more of a private BBS almost. Only a few can dial-in and the rest of the world knows nothing of the content.
I've got a HostGator, dedicated server in Germany and a 1and1 developer account (for a few years now). I'm in the process of moving them all into VPS at slicehost.com. You can start the slices out cheap and work your way up to multiple slices with backnet and public interfaces. So if you need to grow you can do a load balancer on your primary IP and then have other slices doing the work. Their admin tools are pretty easy to deal with too. This option is best if you aren't afraid to administrate your own box though. They have Chat support, forums, articles etc to help people out who are fairly new to system administration with optional backup for your slices.
Glad someone else beat me to suggesting that one. Nothing like scrolling ascii porn to distract people. :)
I've thought about working with either RSS or pushing .torrent files and then having torrent daemon's synce files for me. But so far that's been overly complicated as I have ~1500 production web servers to keep up to date on different code releases depending on what cluster they're in.
/etc/rsync.conf up to date with the potential subnets that we have internally so random outside machines on the WAN can't rsync to our boxes. But we also keep a "lock" table in our database along with the state of each server.
:)
Currently we have a database of our production equipment and we keep track of what cluster/role a server is in. So the boxes all run a cron every minute that checks to see if a new "version" of a release is available (any code change whether a new code release or just an update increments version for that cluster).
Now we're use rsync for our transfer. So we keep our
So we have one super seed if you will which keeps a copy of code for all clusters. When you update a release (kept elsewhere) and then "push" the change you made gets copied to the super seed machine. Once that is done the version gets incremented and then the crons start to look for the new code.
Basic idea to locking we we limit the number of peers a box is allowed to have. So in order to not impact production traffic it's set to 3 currently (plenty fast). So if no "peers" (any machine in the cluster that is not the seed) has the code it will be used first and the boxes that fired off the cron last will sit in a queue (waiting to get a lock on anything with code that hasn't reached it's limit of locks). So when it first starts out the first three boxes will fail over to the super seed. Then the peers will start to get it from those boxes once they are updated.
Doing a code push to our larger cluster used to take 45 minutes to an hour (was done in sequence and not in parallel) but now takes about 5 minutes.
My next goals are to distribute the super seeds and potentially use RPM distribution since I'm working on making the code release only restart the fewest service necessary in order to pick up the changes. And with RPM I can have those commands in the install portion.
That just seems like a horrible idea since they just make it so dust will stick to everything. Not to mention having a high frequency circuit shoved into my case which could be leaking RF into the motherboard seems like a horrible idea as well.
So potentially I would have curruption of the signal on the high speed buses of the mobo (runs slower due to error correction) and dust stuck to everything in my computer to where I'd actually have to wipe the surfaces down.
Silliness...
Man I hope they make a car alarm version. I hate it when Bums lean on my car. :)
Should go re-arrange the lights to spell your name. :)
You are being nice by giving them notice. They can't make you stay longer in order to find a replacement. The fact that your boss can't cope with stress isn't your problem. And in terms of future jobs you can always put down someone else as a reference from the company. Just don't pee on everything on your way out and you should be fine. :)
You can always try out http://www.slimdevices.com. They do wireless server based music systems. And you can play it in every room or separate streams to each room.