The title of the article is misleading. The issue here isn't about putting cameras on private property. As I understand it, the judge was saying that in a place that the police could have searched or could have themselves hidden and watched in person without a warrant they can also put a camera without a warrant. I'm as bothered as just about anybody about the erosion of 4th amendment protections, but this doesn't appear to me to be one of those.
This is not about someone's residence. It is about rules for searching "open fields."
This is an area that it is worth paying someone who knows and has done it several times before. There are brokers who do this for a living, and are good at it. The commission they charge is worth getting it right.
I have no idea about anything having to do with the Megaupload case, but private business influences the actions of government agencies all the time. It isn't as simple as a number you can call, or paying a bribe (which I think is rare in the US). It has more to do with relationships and influence, and yes, influence with a Congressman does play an important part in that mix. It isn't that easy to spot when legitimate influence (which all large lobby and business interests have) steps over the line and becomes corruption.
There is a gap between IM/chat and email and documents, specifically in regard to remote team collaboration. That was one of the strengths of Google Wave, except that Wave had a learning and familiarity threshold people weren't willing to climb over. There's a huge opportunity there for a startup that I haven't seen anybody really tackling yet.
You can't get away from the value of face to face meetings though. If it is possible, getting face to face occasionally is a huge benefit in strengthening relationships in a team. In the end, teams are about relationships. Remote teams work great, and I prefer them to co-located teams, but figuring out a way to meet in person on occasion is worth the effort.
Different people communicate well in different ways. There's a tendency to think there's a right way to do these things. There isn't. You have to have a way for people to chat with each other informally that works for the real people on a real team, and a work environment and culture that encourage it. Whether that can be done remotely or not, or whether it actually works better remotely, depends on the specific people and the relational chemistry of the team.
There are times when a company needs a "rock star," and there are times when that's the last person you want to hire. It takes all kinds, and there is work that is enjoyable for all kinds. If you aren't inclined to stuff that is currently considered cool, you won't get the cool jobs. If what you want is a rewarding and successful career, look for jobs that suit you, that you enjoy, that you are good at. Then build on that. There are a lot of people who have made very solid and successful careers out of stuff that some think is boring.
It is true that things are rarely as simple as we'd like to draw them. It is also true that the current system we have for political contributions breeds corruption, not just in one party or the other, but in our political system in general. Getting into power and staying there is expensive, and it is naive to think that the gifts come without strings. So lists like this are not conclusive evidence of anything other than the raw numbers, but saying you can't draw any useful conclusions is also misleading.
Thanks for taking the time to give that input. It's a valid point about how well we're communicating on the site. My blog post completely aside, I am still genuinely interested in the question I asked in the HN post.
Thanks! That's a very good question, and the honest answer is because we're geeks and design is much harder work for us than building functionality. I guess that's another argument in favor of something like iubenda.com is doing.
As long as we have a sue-happy society, companies will use privacy policies to limit liability. That means they will continue to be documents with more text than most of us are likely to read. Icons and diagrams won't work without the text behind them. However, I do agree that just because a document has legal significance does not mean it needs to be full of legalese. We tried to keep our privacy policy as short and light as possible and write it in plain language. http://nodeping.com/PrivacyPolicy
I'd agree that a balancing proxy is more appropriate for HA. The post mentions that this is specifically not intended as a high availability solution. It's a fairly narrow use.
I don't think that "it was never designed to" and what you should do with a technology necessarily go together. A lot of innovation comes from doing things with technology that it was not originally designed to do. You should be aware that you are beyond the intended purpose, but you should not let that stop you.
I think the issues are the same as they always have been. No matter what your platform, you can't trust user input. Your OS has to be as secure as it is reasonable to make it. Obscurity is not security. Security is an onion. Don't store unencrypted passwords. I could go on for days with apparently trite security aphorisms, but we ignore them at our peril. The issues that are raised in the articles linked in other comments here are not new.
People have been showing scary insecurity demonstrations for decades, and they will for decades more. In any given instance it may or may not mean a thing. People have been picking on one or another popular language or platform or database forever as well, and still companies manage to build successful products and businesses on those very tools.
If you are building something people might actually use, you do have a responsibility to weigh the security issues carefully. Don't let that stop you from building something that people will use, in a way and in a time frame that it is viable for to build it.
I laughed at both your initial response and IsaacSchlueter's comment. Valid points from both.
It would have been a little odd for me to say "Nice use case for Python" considering the original post was about Node, and specifically said they tried writing it in Python but "writing asynchronous code in Python is like using your keys to open a beer bottle." That also made me laugh.
In fact, the original article specifically talked about why Node.js was a good choice for this use case. I agree. Not that you couldn't do it in other ways. Erlang would also be a good choice here, I'm sure. There is always more than one way to do most anything. Still, and in spite of the fact that Node might be getting too much hype, it is an excellent tool for this type of async need.
I think you've hit on the key point when talking about writing. You have to do what works for your style, and for the way your own brain works. Everybody else's statements about what they do are interesting, but in the end the only way to get good at something is to do it. With writing, you have to find your own voice, and methods that work for you, and not worry about whether your approach matches anyone else.
How does this compare to the various existing Lucene based search options for CouchDB? The post says the new Cloudant Search "is a way that would not require you to set up a third-party, financially or operationally expensive solution." Adding basic Lucene searches to a CouchDB setup isn't all that hard. What about elasticsearch and solr? Aside from the cost and hosting, are there other differentiaters between Cloudant's Search and these third party options?
I've learned to pay people to do the things they know well and I don't, and use the time gained to have people pay me for the things I like doing and am good at. Use an accountant, and be happy about paying them to do their job. Find an accountant who you actually like working with, and likes doing what they do. Then spend your time doing the things you are best at, the things other people are happy to pay you to do.
This is not about someone's residence. It is about rules for searching "open fields."