I used to believe (and teach) that comments were a good and necessary thing. Especially "why comments" even bordering on telling the "why" story along side the "how" in the code. The theory was that keeping the two parts of the story together acted as a cross-check during code review and a guide during development and maintenance. That methodology worked really well for a long time, though it did have it's occasional problems. I have now abandoned that methodology and have begun teaching and requiring a fully integrated alternative.
It was a painful transition, but I have been convinced that the best code does a good job at telling both the why and the how. Source code should not be viewed simply as instructions for the computer but rather as an intermediate language that can be shared between the software developers and machines. Both hardware and wetware should be able to interpret the source code with precision and some deeper understanding. It is harder to write that kind of code, but the extra effort has made a profound difference in the quality and maintainability of my code since... Now I teach it the new way.
A case in point: I recently had to hand off some of my code to a developer who was completely unfamiliar with the project without much time budgeted for getting them up to speed on it. I was prepared for all the usual breakage and frustration associated with that kind of forced hand-off. Since that code was written with a fully integrated approach in mind the new developer was able to get up to speed quickly and complete their project without any significant learning effort and without any significant errors along the way. Comparing this case with similar cases in the past the "costs" associated with this new methodology are "in the noise" compared to the old.
We have a similar problem at the Mad Lab - we generate a lot of data (from our digital studio and other projects), we need access all the time, and we need reliable storage.
At first we were putting lots of drives into a PC -- but that led to problems. For one thing there was a single point of failure (main board, power supply, take your pick). Another problem was that the system was loud and power hungry. Then there was the backup problem -- there was no efficient way to do it without building another system just like it --- you can't ship TB of data off-site via the 'Net for backups, it just isn't practical. Then to make matters worse we decided we couldn't do anything else with the server without putting our data at risk... that was the last straw for me -- The server was overkill for the task and couldn't be used for anything else. I was stuck in a paradigm - I knew better - but I'd forgotten that temporarily...
Then I hit upon the solution of using D-Link 2-Bay network storage devices. http://www.dlink.com/products/?pid=509 These little guys are reliable, solid, efficient, and affordable. They're also pretty green because they will spin down when you're not using them thus saving power and POH time on the drives.
We use them in pairs: NS0 for storage, and BS0 for backup. With a firmware upgrade they will do NFS - so we have one of our servers map the two devices and then rsync NS0 to BS0 once per day. Newer versions may have the NFS capability built in (it was on it's way, it was beta firmware when we did it).
Now we have the key features of the high-end NAS solutions we use in data centers, but we have it on the cheap. The solution is scalable (more storage, more enclosures), reliable (mirrored drives all around, fast and easy to access (NFS or Samba - take your pick), provides redundancy (outboard power supply for each enclosure - easy to swap, separate controller for each pair of drives), and easy to manage (what's not to love about a scheduled rsync task via nfs for automated backups?).
We can easily access the data from either windows or *nix boxen on the internal network without any trouble. When we need to access the data from outside the Mad Lab we shell into a server and sftp what we need from there.
Here is a pic of the two of them in the rack: http://www.lifeatwarp9.com/wp-content/uploads/2010/01/MadRackBefore-225x300.jpg We've been using this setup for quite a while now and it's been dead solid. When we need to expand we just plug in another unit and map it. We've also installed this kind of configuration in customer facilities to manage backups and solve other storage problems on the cheap.
You will probably want to go the other way with it... Instead of sitting around a table facing each-other, have them sitting inside a ring facing away from each-other.
I've had teams work lots of different ways --- the ring idea has always worked best.
Most of the time when they want quick collaboration it involves something like "take a look at this" -- either on a note pad, or more commonly on a screen. When facing a table the only way to do that is turn the screens (trouble) or walk around (inconvenient).
With the ring concept a quick turn of the chair does the trick and they are face-to-face or co-piloting a workstation.
Also -- when they don't want to be distracted the ear-buds go in and they're facing away from everything.
Also (I know this isn't on most folks radar) -- sneezes an coughs go AWAY from the other devs, so it's not so easy to spread colds etc.
Finally -- from inside the circle the walls of the circle are large and offer a lot of space for personal effects, charts, artwork, etc... It provides a good opportunity for personal expression without adding extra real-estate.
Get in the circle -- you'll be glad you did for lots of reasons.
We've been doing this with Message Sniffer since day 1 (many years now!). It's very effective. In fact some of the first rules we coded (abstracts we call them) are still active and effective. Along the way we've developed automation to help us see key pieces of these patterns in real-time, and bots to take advantage of other vectors, but the process is still fundamentally the same for template driven spam.
It should be noted that this vector breaks down badly when the spam template is strongly modeled after legitimate messages - such is the case for many phishing spam.
Clearly it is not a complete solution either -- I'd say that it's good for more than 40% of new spam campaigns and less than 70% on average.
I have used many IDEs over the years from Borland, M$oft, Metrowerks, IBM - but now I use Code::Blocks.
I write primarily cross-platform command line and server apps.
What I like about C::B is that it doesn't get in my way and I can easily switch back and forth between my Windows and Linux machines without skipping a beat. Using MinGW under the covers and watching my coding I am able to truly "write once & run everywhere".
C::B gives me the basic things I need and then gets out of the way... What's not to love?
I could use anything -- but C::B is consistently getting the job done for me.
I also poke at things from time to time with Visual Slick Edit and of course VIM... but I wouldn't classify either of those as IDEs (not the way I use them anyway)
1. Do not show anything that will violate your current or prior agreements. If you are asked to do so then walk away.
2. Do prepare some reasonably substantial work of your own even if it's only purpose is to be part of your resume. Make it your best quality work and be prepared to go through it and explain your design choices. That is how I will know it's your code, that you have a clue, and how you will fit into our team.
Think of it this way: You've got time to prepare your resume. So you've got time to write some code. It's part of the project.
If you are not prepared to go through this exercise then you are at best just another applicant. There are plenty of folks out there touting degree this and cert that and I worked on thus-n-such, but can't show you... Most of those folks are disasters looking for a place to happen.
On the other hand, if you are prepared then you've shown me what you can do and that you "get it". I'm not asking for much -- this is what you do right? You are proud of your work? You do care about it right? You are still developing your skills and expanding your craft right? So - show me!
The kind of developers I want are the ones who code not just as a job, but because it's what they do and part of who they are -- folks like that generally have lots of little tid-bits floating around that belong only to them, or they can come up with something on short notice with almost no effort. The best are those that wrote something kewl last weekend to try out something new and can't wait to show it off! Those are the guys with a shot at ending the interview with a new position! (instead of a call-back, maybe...)
Zombie coders with crushed souls looking to punch a clock need not apply.
The more "fire" you can show me about "your craft" the better. I want creativity, competence, and heart. -- no clock punching monkeys and especially not the arrogant guys that are too good to be bothered showing some work. Too busy to do it? Then you'll either burn out (if you're not already), or you don't have chops, or you're so damaged and abrasive that you'll hurt team dynamics, or some other ugly thing I don't want.
Hint: Contributions to open source projects can be great examples... but don't make me hunt for them. Bring them in and show them off!
You're a developer -- you claim you've got game, so show me!
I use SyncBack on my XP laptop to keep backups and on occasion to synchronize shared data between more than one machine. Usually it works well and isn't too hard to set up.
This is what is wrong with publicly traded companies. Even if they started with passion, ideals and vision, once they "go public" they are inevitably governed by market forces and greed - thus evaporating anything good about them. Any time there is a conflict in the board room between "the right thing" and "the profitable thing", "the right thing" has slim chance and anyone pushing "the right thing" quickly loses credibility - or worse.
It is sad that so many business plans say something like "do something that looks good and then get bought by some mega-corp". I say be careful what you wish for you might get it. Sometimes I think the next time I'm at a business lunch and somebody says "we're all in this to make money" I'm going to have to do something... "memorable".
The world needs more businesses run by passion first and money second. Thankfully I am involved in a few of them.:-)
Think about it... you are going to spend most of your life doing this stuff- Wouldn't you rather spend that time doing something meaningful; something "on purpose": Something that matters.
What we really need is DSQP (Dynamic Squelch Propagation Protocol).
If a bot (or any system) sends stuff I don't want (such as detected spam or virii, or probe/hack attempts) my system (server, firewall, etc) can send back a packet that means - don't talk to me like that (I don't want traffic from that address to any of these (specify/all) ports on my system).
A router/firewall that understands DSQP along that path will check to see if a packet from the original source was sent to my system and if it was it will record the squelch request and honor it- it will also pass on the packet so that other such devices along the path will have a chance to honor the request.
Think about this for a second... A PC on your network, in theory, should NEVER receive a legitimate DSQP request under normal circumstances. If it did - that would be a VERY strong signal that there is something wrong with that box and the signal would be VERY easy to spot. Under the right conditions your local routers and/or switches could effectively disconnect such a box and alert you to the problem - potentially saving you from enormous damages. Before you freak out about automatically disabling devices on your corporate network, remember that in order for a DSQP request to be legitimate the source must have sent a packet to the destination and the destination must have actively requested that the source shut up! This is not easy to fake - and certainly your router would know if your local equipment sent packets to the DSQP request source.
As long as packets continue to emerge from a source that violates squelch requests along the way those packets will be dropped or rejected. If the source continues to violate the request then one or more intermediate routers/firewalls will make their own requests. The requests therefore continue to migrate outward toward the source if it continues to transmit unwanted packets.
Some place close to the source where a legitimate router (or DSLAM for example) gets enough of these requests and re-requests and violations, the source may be semi-permanently disconnected for violating their provider's TOS. They will remain there until they are fixed. If they get unfixed they will be squelched and/or disconnected again. By the same token -- most of the action is automatic and self correcting. Once the device stops violating the squelch request, the door is open for it to try again - just in case it was a misunderstanding (or, for example, grandma got her son to come by the house and disinfect her PC).
The protocol is not centralized so there is nobody and no central device/service to corrupt.
The protocol is not censorship because "I" can't stop "you" from getting packets from "him" -- I can only stop "him" from sending packets to me. What happens between "you" and "him" is up to "you".
If you try to abuse the system you get ignored--- that is, if you request that a source not send you packets and the intermediate devices have no record of a packet from that source to your destination then your request is inert. This also means you can't spoof the system to attack/shut-down a source of your chosing by pretending that it sent you unwanted packets and flooding it with DSQP requests. Even if you did manage to pick a source that was sending you data - that source would still be allowed to send data to other destinations - just not you.
If this kind of attack comes from your infected computer then - sure - you might not be able to see google because the bot on your box tried to participate in a google centric DSQP attack -- but if that's the case then you should fix your computer anyway. This might be the heads-up you need. The rest of us will be just fine.
A few of the arguments against this idea (that I've heard in the past):
* You'll never get anybody to even try it: So far so good. Nobody even discusses it seriously at this point and I don't have the time right now to mount any kind of campaign for it. I will continue
If you had enough fuel to slow yourself down to something resembling a dead stop before running deeply into the atmosphere, then you could re-enter without having to deal with such extreme speeds and the associated heat. You could fall back into the atmosphere in some high drag configuration resembling the re-entry procedure used by Space Ship 1 (Scaled Composites et al).
In fact, if you could have an even more efficient engine then you could conceivably make your re-entry without ever exceeding the speed of sound within the atmosphere...
Unfortunately, this kind of efficiency simply doesn't exist in the engine technologies we have today. Also, part of the point of getting into LEO is to go fast - that is, unless you're trying to leave orbit in which case you're trying to go really fast.
It might be possible to bring along enough fuel to do something like this... but if you did then you probably couldn't cary anything else - so there would be no money for the trip (no payload, no ticket).
So, we're left with the compromize... the more heat you can take, and the less your fuel load, the more efficient you can be in getting from here to there. The scramjet lets them leave a ton (ok, several tons) of oxidizer on the ground... Take that weight reduction add the cost of a few exotic metals to take the heat, and you've got plenty of room left for payload.
Once it gets cheap enough to get from here to there, really, really, fast - there will be plenty of money for the exotic metals... Remember, once upon a time the idea of paying $10 to mail a letter was just plain laughable. Now you can't watch a good football game without seeing a dozen ads for overnight letter cariers... and let's face it: who among us has never waited to the last minute to get something done? When the grade is pass/fail you pay what it takes -- if you can. (with Concord, people couldn't - so it's dead now:-( oops! )
This misses the point entirely. All successful surviving species have some important things in common:
They are flexible.
They are resilient.
They breed relativley fast.
They are mobile and fast.
They explore and exploit new habitats.
Bottom line here people: If we do not get off this rock and into space (new habitats) we may not survive the next "big event" here at home - whatever that may be.
This imperitive is, in fact, in our breeding. What we call the "ideology of adventure" is merely this instinct asserting itself. We don't always recognize this fact, but if we were not "adventurous" we would not be here to discuss it. We would have died out in an ice age, or gotten wiped out by some giant rock from space, or some other mass extinction event.
The fact that we are here at all is a testiment to the fact that we are born explorers (at least some of us - enough of us) and that our ancesters happened to be somewhere else when most of their cousins baught it in some big ugly.
All politics aside, please! and I mean that in a "take my wife" sort of way. Get me on the next rocket ship to the new colony wherever... and by the way get on with it - because I want to be part of that crowd that is somewhere else when this blue ball of wet rock takes it's next hit...
Anybody who thinks exploring space is just an adventure, like some E-ticket tourist attraction with a high price tag, has totally missed the point... Exploration of space, deep oceans, or any other niche we can reach is of vital importance in the long run... The fact that it's fun for us is just as biologically imperitive as sex feeling good - and for good reason.
True, but the sheer number of emmitters and the limited bandwidth available for efficient transfer through the atmosphere will impose some important limits I suspect.
Excuse me, but is there another potential technical challenge to be overcome?
Won't a large array of coherent power sources, presumably very close in frequency, and at varying distances by definition interfere with eachother and thereby reduce the efficiency of energy transfer quite a bit?
A single 100 Gazillion Watt laser has an advantage in coherency over a Gazillion 100 watt lasers - no matter how you measure Gazillion.
Did I miss something in physics class?
I'm pretty sure I'm right about this, and probably not the first to think about it - so what is the loss due to the generation of interference patterns at the collection point?
Is there a point of diminishing returns where increasing the number of lasers becomes less efficient than increasing the size of the lasers?
If so, does that point define an optimum output per source for a given launch vehicle?
What about increasing the size of the collector and diverging the targeting pionts of the sources to minimize overlap - is that even worth doing?
What about multiple diverse collectors for redundancy and an improvement in power transfer efficiency and if so, at what point does that strategy reach diminishing returns due to increased complexity, weight, and drag?
You will probably get a lot of grief from folks about doing this. I know I do... but so far, I've been quite happy and so have my friends/family.
I've seen this work really well and really badly. There are some tricks to it, and it definitely has to be the right group of enlightened, well rounded, reasonably self-actualized people to make it work. Dysfunctional families need not apply!
Right now I have my brother, my wife, and my oldest son all working with me and it couldn't be better. We all get along, we all do our jobs, and we are having a great time doing it... Even better, we have a level of trust and companionship and sensitivity that goes far beyond what people ever expect to see in even the best "conventional" office setting. One nice thing that goes along with this is that as a team we out produce every "conventional" group we come up against.
A couple of the "tricks" that seem to make this work (there are really too many to list):
You must agree on ethics and business practices. If you don't then there will be constant conflict.
You must be very clear on responsibilities and on the chain of command. This can work even in "flat" organizations (my favorite) but it must be in place.
Take care to manage expectations carefully. It is much easier for family members to make assumptions about what others will or should take responsibility for, or what they will do as a "favor". If your group has trouble with this in the family unit then you will never make it working together - or worse - you will and it will be a living hell. This one is particularly dangerous and easy to slip into! I can't over state it. Be particularly careful of your own expectations - you NEVER want to find yourself in the position of taking advantage - even a little bit - even if the target of this advantage is begging to have you do it! Keep things fair and well in check. Ask yourself - if my xyz came home from another job and told me this story would I still think it was fair?
You must trust eachother implicitly and you must have a completely "open book" policy. If you find yourself in a position where you need to hide information from someone it is time to get them out.
You must have similar goals and thick skins. Remember that everyone is in this together.
You must be constantly watching out for any signs of blame casting or other divisive behaviors. If you see it, it is time to settle it and remind everyone that this can't be allowed. It's no different than any tight knit team - but it can be a bit more explosive and a bit more dangerous.
Don't hire family or friends that aren't up to the job. If there is a better candidate elsewhere then they should get the job. There is no room for entitlements! Be sure your other employees know this too - by demonstrating it regularly.
Be extremely mindful of non-family employees and what they percieve. You will be surprized what seemingly happy employees are thinking that they won't tell you - especially where working family members are concerned. You must be very clear to every employee that is a family member - they are responsible for earning the trust and respect of every other person around them and they must really focus on this - it doesn't happen automatically. They should think of this as an extra job. The other employees around them should feel absolutely certain at all times that the family member has their position because they are the best one for the job - not becuase of any kind of favoritism. It helps (though this sounds like a contradiction) if the family members work longer hours and take on tough assignments more readily than normal employees do. This helps to demonstrate a level of effort and committment that will put the regular employee(s) at ease about what they will always view as a special position. There's no way to keep them from viewing things that way - but you can make sure they feel the special position is justifiable.
Actually, I think you've inadvertently made my point. You see, there is a ripple effect associated with this dynamic data. Like dominos tumbling in a time line away from each event. The original "soul" is bound as much in that causal chain as in the stored consciousness, etc...
My opinion is that this dynamic data - the causal chain flowing away from the previous existence - is a vital part of the origininal soul. Any new copy that is distinct from that chain is incomplete. Any new copy that introduces it's own is a corrupting influence.
Perhaps it is a matter of differing philosophies - but I would consider that any "instance" of a given consciousness would be distinct by nature of this dynamic data. In fact I think, perhaps, the dynamic data may be more profound than the consciousness itself. So where you would say each of these are part of a single "soul" I would say they are distinct - but perhaps bound in some way.
This line of thinking leaves out an important piece of the puzzle.
A living sentient being occupies a single place in the universe and interacts with the universe from that perspective. Therefore part of their "soul" is bound to that interaction.
Simply transporting their "consciousness" into another mechanism doesn't solve the whole problem. The "dynamic data" bound in their previous interactions is not necessarily transferred - nor can it be due to quantum level uncertainty.
In addition, since the new mechanism did not instantly and miraculously appear at the moment of transferrence - that new mechanism has already established a partial history of it's own... and continues to represent it's own dynamic data. How much of this dynamic data can be said to represent a previous "soul". Is that "soul" lost when the transferrence takes place? Is it absorbed? Was it always fated to be part of the new soul?
Also consider that if the ability to copy this consciousness exists then replication rather than transferrence may result - leading to additional problems related to the first. Specifically that there may be more than one set of ongoing interactions where only one "existence" was previously allowed. Does this then become more than one soul? The same soul split? New souls all together?
The ongoing, dynamic interactions of the first mechanism represent some part of the original "soul"... If the "consciousness" is transferred into a different mechanism, and the first mechanism is destroyed - then how much of that sould died with the original mechanism?
I was alerted to this article by a post on the Declude Junkmail list. My response to that list included an alternative implementation of the delay-before-receipt methodology that avoids some of the pit-falls.
The premise of my response seems to be well covered: specifically that the spammers can easily adapt to "Greylisting" as it is described and that the resulting adaptation is worse than the original problem... Having said that I have an alternative to offer from our ongoing research.
Here is part of that response/description:
---
I've considered a similar protocol that would force the required complexity on the spammers but since it would require broad deployment to be effective the methodology has been shelved (at least for now). Here is a short description of the IRRQ protocol. (IRRQ = Intelligent Retry Request).
IRRQ adjusts the SMTP protocol by enforcing a lightweight authentication (automated challenge) for new senders to an MTA. IRRQ is still in consideration for later deployment as part of a COT protocol suite in SortMonster. (COT = Circle Of Trust).
1. A new sender (SMTP SENDER + SOURCE MTA) attempts to deliver a message.
2. The new sender is not in the local COT reference so their message is initially rejected with a temporary failure. However the temporary failure messages is modified to include an authentication code (in the form of a special email address) for future retries of this message. The authentication code is a secure one-time-pad.
<=== 451 Please try again later using <9sk2o39q0s1l@thisdomain.com>
3. The sending MTA stores the authentication code with the message to be retried. The receiving MTA stores the authentication message and envelope information with an expiration time and a guard time.
4. The receiving MTA may perform other operations to automatically or manually white-list the new sender. For example, in a COT model the peers in the local COT might be queried for a rating of the sender or an acceptance policy. As a result any sending MTAs that are not implementing the protocol can be accommodated after the delay dependent upon the policies of the receiving MTA and the services (such as COT, RBLs, etc.) at it's disposal.
5. The sending MTA retries the message after a given guard time (established by policies, but typically between 15 and 120 minutes). In this retry the authentication code is added to the envelope and sent as the first recipient.
===> RCPT TO: <9sk2o39q0s1l@thisdomain.com>
6. The receiving MTA recognizes the authentication code and retrieves it's stored copy of the envelope for verification. The sending MTA completes the envelope and if it matches the stored version the message is accepted normally.
7. The authentication message is retired and may be stored for a period in order to detect hack attempts. A particular authentication code can only be used once legitimately.
NOTE 1: Sending MTAs that do not implement IRRQ are not effected by the adjustments to the protocol and may still be accepted based on policy decisions evaluated in step 4.
NOTE 2: Attempts to hack IRRQ by sending falsified authentication codes, reusing codes, or altering the envelope associated with the code will result in strong negative ratings within a COT.
NOTE 3: This methodology strongly biases the mail system against spammers by forcing legitimate senders to properly implement the retry protocol. Spammers typically use systems which transmit messages (on the fly) without regard to bounces or other response messages. Simple re-transmission counters to the IRRQ protocol will not be effective.
Slashdot Mirror
I used to believe (and teach) that comments were a good and necessary thing. Especially "why comments" even bordering on telling the "why" story along side the "how" in the code. The theory was that keeping the two parts of the story together acted as a cross-check during code review and a guide during development and maintenance. That methodology worked really well for a long time, though it did have it's occasional problems. I have now abandoned that methodology and have begun teaching and requiring a fully integrated alternative.
It was a painful transition, but I have been convinced that the best code does a good job at telling both the why and the how. Source code should not be viewed simply as instructions for the computer but rather as an intermediate language that can be shared between the software developers and machines. Both hardware and wetware should be able to interpret the source code with precision and some deeper understanding. It is harder to write that kind of code, but the extra effort has made a profound difference in the quality and maintainability of my code since... Now I teach it the new way.
Here is a blog post I made at the beginning of that transition: http://www.lifeatwarp9.com/2011/02/comments-are-not-literature-i-must-be-mad/
A case in point: I recently had to hand off some of my code to a developer who was completely unfamiliar with the project without much time budgeted for getting them up to speed on it. I was prepared for all the usual breakage and frustration associated with that kind of forced hand-off. Since that code was written with a fully integrated approach in mind the new developer was able to get up to speed quickly and complete their project without any significant learning effort and without any significant errors along the way. Comparing this case with similar cases in the past the "costs" associated with this new methodology are "in the noise" compared to the old.
We have a similar problem at the Mad Lab - we generate a lot of data (from our digital studio and other projects), we need access all the time, and we need reliable storage.
At first we were putting lots of drives into a PC -- but that led to problems. For one thing there was a single point of failure (main board, power supply, take your pick). Another problem was that the system was loud and power hungry. Then there was the backup problem -- there was no efficient way to do it without building another system just like it --- you can't ship TB of data off-site via the 'Net for backups, it just isn't practical. Then to make matters worse we decided we couldn't do anything else with the server without putting our data at risk... that was the last straw for me -- The server was overkill for the task and couldn't be used for anything else. I was stuck in a paradigm - I knew better - but I'd forgotten that temporarily...
Then I hit upon the solution of using D-Link 2-Bay network storage devices. http://www.dlink.com/products/?pid=509 These little guys are reliable, solid, efficient, and affordable. They're also pretty green because they will spin down when you're not using them thus saving power and POH time on the drives.
We use them in pairs: NS0 for storage, and BS0 for backup. With a firmware upgrade they will do NFS - so we have one of our servers map the two devices and then rsync NS0 to BS0 once per day. Newer versions may have the NFS capability built in (it was on it's way, it was beta firmware when we did it).
Now we have the key features of the high-end NAS solutions we use in data centers, but we have it on the cheap. The solution is scalable (more storage, more enclosures), reliable (mirrored drives all around, fast and easy to access (NFS or Samba - take your pick), provides redundancy (outboard power supply for each enclosure - easy to swap, separate controller for each pair of drives), and easy to manage (what's not to love about a scheduled rsync task via nfs for automated backups?).
We can easily access the data from either windows or *nix boxen on the internal network without any trouble. When we need to access the data from outside the Mad Lab we shell into a server and sftp what we need from there.
Here is a pic of the two of them in the rack: http://www.lifeatwarp9.com/wp-content/uploads/2010/01/MadRackBefore-225x300.jpg We've been using this setup for quite a while now and it's been dead solid. When we need to expand we just plug in another unit and map it. We've also installed this kind of configuration in customer facilities to manage backups and solve other storage problems on the cheap.
_M
You will probably want to go the other way with it... Instead of sitting around a table facing each-other, have them sitting inside a ring facing away from each-other.
I've had teams work lots of different ways --- the ring idea has always worked best.
Most of the time when they want quick collaboration it involves something like "take a look at this" -- either on a note pad, or more commonly on a screen. When facing a table the only way to do that is turn the screens (trouble) or walk around (inconvenient).
With the ring concept a quick turn of the chair does the trick and they are face-to-face or co-piloting a workstation.
Also -- when they don't want to be distracted the ear-buds go in and they're facing away from everything.
Also (I know this isn't on most folks radar) -- sneezes an coughs go AWAY from the other devs, so it's not so easy to spread colds etc.
Finally -- from inside the circle the walls of the circle are large and offer a lot of space for personal effects, charts, artwork, etc... It provides a good opportunity for personal expression without adding extra real-estate.
Get in the circle -- you'll be glad you did for lots of reasons.
_M
We've been doing this with Message Sniffer since day 1 (many years now!). It's very effective. In fact some of the first rules we coded (abstracts we call them) are still active and effective. Along the way we've developed automation to help us see key pieces of these patterns in real-time, and bots to take advantage of other vectors, but the process is still fundamentally the same for template driven spam.
It should be noted that this vector breaks down badly when the spam template is strongly modeled after legitimate messages - such is the case for many phishing spam.
Clearly it is not a complete solution either -- I'd say that it's good for more than 40% of new spam campaigns and less than 70% on average.
I have used many IDEs over the years from Borland, M$oft, Metrowerks, IBM - but now I use Code::Blocks.
I write primarily cross-platform command line and server apps.
What I like about C::B is that it doesn't get in my way and I can easily switch back and forth between my Windows and Linux machines without skipping a beat. Using MinGW under the covers and watching my coding I am able to truly "write once & run everywhere".
C::B gives me the basic things I need and then gets out of the way... What's not to love?
I could use anything -- but C::B is consistently getting the job done for me.
I also poke at things from time to time with Visual Slick Edit and of course VIM ... but I wouldn't classify either of those as IDEs (not the way I use them anyway)
I can tell you a couple of things:
1. Do not show anything that will violate your current or prior agreements. If you are asked to do so then walk away.
2. Do prepare some reasonably substantial work of your own even if it's only purpose is to be part of your resume. Make it your best quality work and be prepared to go through it and explain your design choices. That is how I will know it's your code, that you have a clue, and how you will fit into our team.
Think of it this way: You've got time to prepare your resume. So you've got time to write some code. It's part of the project.
If you are not prepared to go through this exercise then you are at best just another applicant. There are plenty of folks out there touting degree this and cert that and I worked on thus-n-such, but can't show you... Most of those folks are disasters looking for a place to happen.
On the other hand, if you are prepared then you've shown me what you can do and that you "get it". I'm not asking for much -- this is what you do right? You are proud of your work? You do care about it right? You are still developing your skills and expanding your craft right? So - show me!
The kind of developers I want are the ones who code not just as a job, but because it's what they do and part of who they are -- folks like that generally have lots of little tid-bits floating around that belong only to them, or they can come up with something on short notice with almost no effort. The best are those that wrote something kewl last weekend to try out something new and can't wait to show it off! Those are the guys with a shot at ending the interview with a new position! (instead of a call-back, maybe...)
Zombie coders with crushed souls looking to punch a clock need not apply.
The more "fire" you can show me about "your craft" the better. I want creativity, competence, and heart. -- no clock punching monkeys and especially not the arrogant guys that are too good to be bothered showing some work. Too busy to do it? Then you'll either burn out (if you're not already), or you don't have chops, or you're so damaged and abrasive that you'll hurt team dynamics, or some other ugly thing I don't want.
Hint: Contributions to open source projects can be great examples... but don't make me hunt for them. Bring them in and show them off!
You're a developer -- you claim you've got game, so show me!
I use SyncBack on my XP laptop to keep backups and on occasion to synchronize shared data between more than one machine. Usually it works well and isn't too hard to set up.
http://www.2brightsparks.com/syncback/syncback-hub .html
This is what is wrong with publicly traded companies. Even if they started with passion, ideals and vision, once they "go public" they are inevitably governed by market forces and greed - thus evaporating anything good about them. Any time there is a conflict in the board room between "the right thing" and "the profitable thing", "the right thing" has slim chance and anyone pushing "the right thing" quickly loses credibility - or worse.
It is sad that so many business plans say something like "do something that looks good and then get bought by some mega-corp". I say be careful what you wish for you might get it. Sometimes I think the next time I'm at a business lunch and somebody says "we're all in this to make money" I'm going to have to do something... "memorable".
The world needs more businesses run by passion first and money second. Thankfully I am involved in a few of them. :-)
Think about it... you are going to spend most of your life doing this stuff- Wouldn't you rather spend that time doing something meaningful; something "on purpose": Something that matters.
It strikes me that network coding seems similar to the way information is propagated in the brain.
If a bot (or any system) sends stuff I don't want (such as detected spam or virii, or probe/hack attempts) my system (server, firewall, etc) can send back a packet that means - don't talk to me like that (I don't want traffic from that address to any of these (specify/all) ports on my system).
A router/firewall that understands DSQP along that path will check to see if a packet from the original source was sent to my system and if it was it will record the squelch request and honor it- it will also pass on the packet so that other such devices along the path will have a chance to honor the request.
Think about this for a second... A PC on your network, in theory, should NEVER receive a legitimate DSQP request under normal circumstances. If it did - that would be a VERY strong signal that there is something wrong with that box and the signal would be VERY easy to spot. Under the right conditions your local routers and/or switches could effectively disconnect such a box and alert you to the problem - potentially saving you from enormous damages. Before you freak out about automatically disabling devices on your corporate network, remember that in order for a DSQP request to be legitimate the source must have sent a packet to the destination and the destination must have actively requested that the source shut up! This is not easy to fake - and certainly your router would know if your local equipment sent packets to the DSQP request source.
As long as packets continue to emerge from a source that violates squelch requests along the way those packets will be dropped or rejected. If the source continues to violate the request then one or more intermediate routers/firewalls will make their own requests. The requests therefore continue to migrate outward toward the source if it continues to transmit unwanted packets.
Some place close to the source where a legitimate router (or DSLAM for example) gets enough of these requests and re-requests and violations, the source may be semi-permanently disconnected for violating their provider's TOS. They will remain there until they are fixed. If they get unfixed they will be squelched and/or disconnected again. By the same token -- most of the action is automatic and self correcting. Once the device stops violating the squelch request, the door is open for it to try again - just in case it was a misunderstanding (or, for example, grandma got her son to come by the house and disinfect her PC).
The protocol is not centralized so there is nobody and no central device/service to corrupt.
The protocol is not censorship because "I" can't stop "you" from getting packets from "him" -- I can only stop "him" from sending packets to me. What happens between "you" and "him" is up to "you".
If you try to abuse the system you get ignored--- that is, if you request that a source not send you packets and the intermediate devices have no record of a packet from that source to your destination then your request is inert. This also means you can't spoof the system to attack/shut-down a source of your chosing by pretending that it sent you unwanted packets and flooding it with DSQP requests. Even if you did manage to pick a source that was sending you data - that source would still be allowed to send data to other destinations - just not you.
If this kind of attack comes from your infected computer then - sure - you might not be able to see google because the bot on your box tried to participate in a google centric DSQP attack -- but if that's the case then you should fix your computer anyway. This might be the heads-up you need. The rest of us will be just fine.
A few of the arguments against this idea (that I've heard in the past):
* You'll never get anybody to even try it: So far so good. Nobody even discusses it seriously at this point and I don't have the time right now to mount any kind of campaign for it. I will continue
The real trick is fuel, not heat.
If you had enough fuel to slow yourself down to something resembling a dead stop before running deeply into the atmosphere, then you could re-enter without having to deal with such extreme speeds and the associated heat. You could fall back into the atmosphere in some high drag configuration resembling the re-entry procedure used by Space Ship 1 (Scaled Composites et al).
In fact, if you could have an even more efficient engine then you could conceivably make your re-entry without ever exceeding the speed of sound within the atmosphere...
Unfortunately, this kind of efficiency simply doesn't exist in the engine technologies we have today. Also, part of the point of getting into LEO is to go fast - that is, unless you're trying to leave orbit in which case you're trying to go really fast.
It might be possible to bring along enough fuel to do something like this... but if you did then you probably couldn't cary anything else - so there would be no money for the trip (no payload, no ticket).
So, we're left with the compromize... the more heat you can take, and the less your fuel load, the more efficient you can be in getting from here to there. The scramjet lets them leave a ton (ok, several tons) of oxidizer on the ground... Take that weight reduction add the cost of a few exotic metals to take the heat, and you've got plenty of room left for payload.
Once it gets cheap enough to get from here to there, really, really, fast - there will be plenty of money for the exotic metals... Remember, once upon a time the idea of paying $10 to mail a letter was just plain laughable. Now you can't watch a good football game without seeing a dozen ads for overnight letter cariers... and let's face it: who among us has never waited to the last minute to get something done? When the grade is pass/fail you pay what it takes -- if you can. (with Concord, people couldn't - so it's dead now :-( oops! )
Hope this helps...
_M
This misses the point entirely. All successful surviving species have some important things in common:
Bottom line here people: If we do not get off this rock and into space (new habitats) we may not survive the next "big event" here at home - whatever that may be.
This imperitive is, in fact, in our breeding. What we call the "ideology of adventure" is merely this instinct asserting itself. We don't always recognize this fact, but if we were not "adventurous" we would not be here to discuss it. We would have died out in an ice age, or gotten wiped out by some giant rock from space, or some other mass extinction event.
The fact that we are here at all is a testiment to the fact that we are born explorers (at least some of us - enough of us) and that our ancesters happened to be somewhere else when most of their cousins baught it in some big ugly.
All politics aside, please! and I mean that in a "take my wife" sort of way. Get me on the next rocket ship to the new colony wherever... and by the way get on with it - because I want to be part of that crowd that is somewhere else when this blue ball of wet rock takes it's next hit...
Anybody who thinks exploring space is just an adventure, like some E-ticket tourist attraction with a high price tag, has totally missed the point... Exploration of space, deep oceans, or any other niche we can reach is of vital importance in the long run... The fact that it's fun for us is just as biologically imperitive as sex feeling good - and for good reason.
Lets DO IT!
True, but the sheer number of emmitters and the limited bandwidth available for efficient transfer through the atmosphere will impose some important limits I suspect.
Excuse me, but is there another potential technical challenge to be overcome?
Won't a large array of coherent power sources, presumably very close in frequency, and at varying distances by definition interfere with eachother and thereby reduce the efficiency of energy transfer quite a bit?
A single 100 Gazillion Watt laser has an advantage in coherency over a Gazillion 100 watt lasers - no matter how you measure Gazillion.
Did I miss something in physics class?
I'm pretty sure I'm right about this, and probably not the first to think about it - so what is the loss due to the generation of interference patterns at the collection point?
Is there a point of diminishing returns where increasing the number of lasers becomes less efficient than increasing the size of the lasers?
If so, does that point define an optimum output per source for a given launch vehicle?
What about increasing the size of the collector and diverging the targeting pionts of the sources to minimize overlap - is that even worth doing?
What about multiple diverse collectors for redundancy and an improvement in power transfer efficiency and if so, at what point does that strategy reach diminishing returns due to increased complexity, weight, and drag?
I've seen this work really well and really badly. There are some tricks to it, and it definitely has to be the right group of enlightened, well rounded, reasonably self-actualized people to make it work. Dysfunctional families need not apply!
Right now I have my brother, my wife, and my oldest son all working with me and it couldn't be better. We all get along, we all do our jobs, and we are having a great time doing it... Even better, we have a level of trust and companionship and sensitivity that goes far beyond what people ever expect to see in even the best "conventional" office setting. One nice thing that goes along with this is that as a team we out produce every "conventional" group we come up against.
A couple of the "tricks" that seem to make this work (there are really too many to list):
Those are some of the hilights -
Actually, I think you've inadvertently made my point. You see, there is a ripple effect associated with this dynamic data. Like dominos tumbling in a time line away from each event. The original "soul" is bound as much in that causal chain as in the stored consciousness, etc...
My opinion is that this dynamic data - the causal chain flowing away from the previous existence - is a vital part of the origininal soul. Any new copy that is distinct from that chain is incomplete. Any new copy that introduces it's own is a corrupting influence.
Perhaps it is a matter of differing philosophies - but I would consider that any "instance" of a given consciousness would be distinct by nature of this dynamic data. In fact I think, perhaps, the dynamic data may be more profound than the consciousness itself. So where you would say each of these are part of a single "soul" I would say they are distinct - but perhaps bound in some way.
This line of thinking leaves out an important piece of the puzzle.
A living sentient being occupies a single place in the universe and interacts with the universe from that perspective. Therefore part of their "soul" is bound to that interaction.
Simply transporting their "consciousness" into another mechanism doesn't solve the whole problem. The "dynamic data" bound in their previous interactions is not necessarily transferred - nor can it be due to quantum level uncertainty.
In addition, since the new mechanism did not instantly and miraculously appear at the moment of transferrence - that new mechanism has already established a partial history of it's own... and continues to represent it's own dynamic data. How much of this dynamic data can be said to represent a previous "soul". Is that "soul" lost when the transferrence takes place? Is it absorbed? Was it always fated to be part of the new soul?
Also consider that if the ability to copy this consciousness exists then replication rather than transferrence may result - leading to additional problems related to the first. Specifically that there may be more than one set of ongoing interactions where only one "existence" was previously allowed. Does this then become more than one soul? The same soul split? New souls all together?
The ongoing, dynamic interactions of the first mechanism represent some part of the original "soul"... If the "consciousness" is transferred into a different mechanism, and the first mechanism is destroyed - then how much of that sould died with the original mechanism?
I was alerted to this article by a post on the Declude Junkmail list. My response to that list included an alternative implementation of the delay-before-receipt methodology that avoids some of the pit-falls.
The premise of my response seems to be well covered: specifically that the spammers can easily adapt to "Greylisting" as it is described and that the resulting adaptation is worse than the original problem... Having said that I have an alternative to offer from our ongoing research.
Here is part of that response/description:
---
I've considered a similar protocol that would force the required complexity on the spammers but since it would require broad deployment to be effective the methodology has been shelved (at least for now). Here is a short description of the IRRQ protocol. (IRRQ = Intelligent Retry Request).
IRRQ adjusts the SMTP protocol by enforcing a lightweight authentication (automated challenge) for new senders to an MTA. IRRQ is still in consideration for later deployment as part of a COT protocol suite in SortMonster. (COT = Circle Of Trust).
1. A new sender (SMTP SENDER + SOURCE MTA) attempts to deliver a message.
2. The new sender is not in the local COT reference so their message is initially rejected with a temporary failure. However the temporary failure messages is modified to include an authentication code (in the form of a special email address) for future retries of this message. The authentication code is a secure one-time-pad.
3. The sending MTA stores the authentication code with the message to be retried. The receiving MTA stores the authentication message and envelope information with an expiration time and a guard time.
4. The receiving MTA may perform other operations to automatically or manually white-list the new sender. For example, in a COT model the peers in the local COT might be queried for a rating of the sender or an acceptance policy. As a result any sending MTAs that are not implementing the protocol can be accommodated after the delay dependent upon the policies of the receiving MTA and the services (such as COT, RBLs, etc.) at it's disposal.
5. The sending MTA retries the message after a given guard time (established by policies, but typically between 15 and 120 minutes). In this retry the authentication code is added to the envelope and sent as the first recipient.
6. The receiving MTA recognizes the authentication code and retrieves it's stored copy of the envelope for verification. The sending MTA completes the envelope and if it matches the stored version the message is accepted normally.
7. The authentication message is retired and may be stored for a period in order to detect hack attempts. A particular authentication code can only be used once legitimately.
NOTE 1: Sending MTAs that do not implement IRRQ are not effected by the adjustments to the protocol and may still be accepted based on policy decisions evaluated in step 4.
NOTE 2: Attempts to hack IRRQ by sending falsified authentication codes, reusing codes, or altering the envelope associated with the code will result in strong negative ratings within a COT.
NOTE 3: This methodology strongly biases the mail system against spammers by forcing legitimate senders to properly implement the retry protocol. Spammers typically use systems which transmit messages (on the fly) without regard to bounces or other response messages. Simple re-transmission counters to the IRRQ protocol will not be effective.