Keep I'm mind the company made a decision to use low paid drones and use them as the customer face of the company. They did do the right thing in the end but one should not have to appeal to the media to get proper treatment.

The storm won't be a problem. Quetzalcoatl will be here.

It happened again since the 8th: http://blog.sucuri.net/2010/06/mass-infection-of-iisasp-sites-2677-inyahoo-js.html

When I'm writing code I have two modes: Planning/Collab and hardcore coding. When it comes to planning/collab having an open space is great. Easy to interact, easy to work with others and everyone is heard. For hardcore coding it's time to be segmented away from others. Half walls don't work. Wearing earphones isn't enough. To be as productive as possible I need to concentrate using the ideas and plans from the planning/collab time to write my code.

It's as simple as that. Either have a small team room and individual workspaces free of outside distraction or get a transforming workspace of some kind. No need to listen to the seating experts spout something that 5 years ago was bad but somehow became good again (and will be bad again soon).

I currently work at a place what 'proudly touts' open floor plan for all IT developers. The end result is people really want to work from home when coding to avoid managers interrupting, PM's being PM's, smells of lunch (or worse), people on conference calls, etc..

Oh, and no round tables. It's a waste of space and people still are crowded.

For instance, SonicWall blocks phishtank. Yup, SonicWall blocks a site to help protect users against phishing by being able to check links against known phishing sites (http://www.stevemilner.org/blog/2010/01/20/sonicwall-silly/). The less technical the data owners are the less helpful the the rule sets are.

To be honest, this site in question does look like a phishing site and thus, if someone went to the site and knew what phishing was, they would most likely flag it if they did not click through (aka it isn't a verified phishing site but it sure looks like one at first glance).

Surprise, a company released a hosted service (in this case 'cloud computing') where they did not have well thought through security support. AWS is a hot bed of bad activity. So are many of the other cloud providers (to lesser degrees related to popularity of the service). It's going to get worse before it gets better so make sure your own infra is ready to deal with the attacks through blocking on the edge, host firewalls, IDS, whatever you deem is helpful for your setup ... and don't be afraid to block outright and request the addition of the IP's to a public block list.

But that is just my $0.02.

Of course, someone *could* use an AWS account to send calls to her phone over and over .... but that would be bad :-).

There are number of people posting comments about how this isn't an issue since Apache's code is open. Let me outline a few possible issues even with the code being ...

1. If Apache keeps non-released security information in their bug tracker it could end up being disclosed. Great if you want to get your hands on security issues before patches are released.
2. Private comments can be leaked out which are probably not meant for general consumption. Probably not a huge issue, but it depends on the content.
3. Many people use the same passwords everywhere -- and the same usernames. Any cracked accounts could prove quite useful.


On the flip side it goes to show that XSS and CSRF are, as many security (open and closed) groups note, are a major problem -- and are pretty easy to exploit. While it is not fun to have this occur it may wake up some engineers into seeing that 'if it can happen to Apache maybe we should take it seriously'.

Then there is the whole thing of Apache using Jira instead of something Open ... http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html ... :-)

I think the frustration is actually in some people not using the right tools for the job. I like NoSQL databases (specifically MongoDB), but I have not used them with anything I've written. Why? Because it wasn't the right tool for the job. I tend to use MySQL, Postgres or sqlite because it's so widely available and well known in how to administer. There are times that NoSQL will makes sense, it's just not the area I work in.

I do think we are going to continue seeing an uptick in NoSQL related things since many companies are fixated on "the cloud" while not really knowing what "the cloud" is (heck, no one still really, truly has a common definition of what it means ...). Since NoSQL seems to be a popular tool, and "the cloud" is a popular buzz phrase CIO's/CTO's will likely be pushing their shops to utilize "NoSQL in the cloud". While large scale applications which don't require relational information and need fast syncing across many servers is good grounds for NoSQL, these "NoSQL in the cloud" instances will probably not actually fit that status.

I do agree that it will be a good thing when "NoSQL for everything" dies. Just like it was a good thing when "PERL for everything", "Java for everything" and "Ruby for everything" died, but let's not throw out the whole idea because a lot of people use it wrong.

I assume some social sites require you to be you by way of their terms or EULA ... I guess they can get around that? I mean, it makes sense they would read public information but if they are using fake profiles without prior approval for a case it seems like something is going wrong ...

Exactly what I thought as well. I have a feeling the Twitter API was picked since status.net supports it too http://status.net/wiki/Twitter-compatible_API.

They will need a SPICE rack.