mpk

PlantUML supports this https://plantuml.com/handwritten

Add this to any diagram to get the effect you want,

  skinparam handwritten true
  skinparam monochrome true

The EU has restrictions on this kind of stuff - http://ec.europa.eu/justice/data-protection/data-collection/...

Yes, that would be normal. During an acquisition the future is unknown so you don't have a reliable roadmap you can use to set or update development goals. Other activities that take away from development could be developers working on capability demonstration or participating in technical due diligence.

(I don't know anything about the rethinkdb situation, I'm just speaking generally here)

Ember is fantastic, the oldest projects I have are about 4 years old and have been (more-or-less) painlessly upgraded every now and again. Everything is ember-cli and ember-cli-deploy now. Time and time again it shows that Ember is a community project that has a strong focus on scalability and maintainability over time.

I also do a lot of work in Angular and React (this year) and all the tooling, build, best practices change every couple of months.

A lot of people complain about Ember's learning curve, but the things you learn _stay relevant_. Personally I'd rather invest in that kind of knowledge than learning yet another arbitrary build system.

That works very well combined with RFC 6902 - JSON-PATCH for partial changes to JSON objects, which in turn works nicely with HTTP PATCH method, RFC 5789.

Uh, Gates not a programmer? You might want to check your history. By all accounts he is, or was, an excellent programmer who definitely got his hands dirty.

[edit add refs] Joel's Bill interview - http://www.joelonsoftware.com/items/2006/06/16.html

Pancake problem - http://archive.today/20120916031916/http://www.npr.org/templ...

Needs an active FB session to read.

Not to rain on anybody's parade here, but for first-time vim users I recommend not using any plugins and only selectively adding them one at a time after the basics (buffers, navigation, some ex mode, etc) are at least somewhat familiar.

Getting started with plugins enabled makes it hard to understand where vim stops and plugins begin and make switching to a different (someone else's) vim setup confusing at best.

It also tends to feed the 'make it work like the last editor I used' syndrome, which is completely counter-productive.

Otherwise, nice work and good job open-sourcing it!

That depends on how long it's been in the codebase. As this case is covered in the Rails security guide _and_ the Ruby security reviewer's guide I'd expect it to be quite old and now being found because it hasn't been properly audited before or indicate that the review process needs some work.

This article contains a number of fallacies. Storing sessions on disk? Over NFS? In the database? Please - no-one does that. And random MySQL bashing? What's that based on? MySQL is used by many high-volume shops to handle huge amounts of data. (See - I don't have to quote examples either!) And magic Oracle scales to infinity? For the kinds of database setups you need with high-performance web apps you can throw the same amount of money at percona.com and get there as well.

[Edit - didn't notice this was a 2004 article]

I'd like to know too, but I'm not skeptical of the 200k figure. If this is going to work then it's not going to be a solo effort, so let's say one or two more devs and someone to do QA or support or design or whatever and this budget is looking pretty tight.

If I'm on hacker news and I see the word cracking, I immediately hope this'll be some old school "let's open up IDA and see what's what here" article.

"And a Basecamp user uploaded the 100,000,000th file (It was a picture of a cat!)"

Aren't you supposed to treat user data as confidential and not examine the contents?

example.com is protected by RFC 2606 ("Reserved Top Level DNS Names") for special use (with example.org and example.net - along the same lines as the reservation for 127/24, 192.168/16, etc).

The domain is owned by ICANN and has no MX record. Where the mail goes depends on your site-local MTA configuration. On the public internet it goes (or should go) nowhere and bounce back immediately with an appropriate status code from your provider's MTA.

Actually you're both wrong and a little right.

I think you both imagine that transfusions are 1 on 1. (1 donor, 1 recipient). In this case, the numbers you present kind-of work out. And sure, a risk of HIV (or whatever) infection versus certain death is worth it in any scenario. (Especially now that HIV/AIDS is chronic and treatable rather than terminal).

Many scenarios involve heavy blood loss and require more than what is normally given by a donor in a single donation. This means drawing on the pool of available blood, so multiple donations will be used of the same type, but they won't be from the same donor.

This raises the risk of transfusing infected blood significantly which is one of the reasons that the screening for blood donation harshly excludes anyone who fits in one or more higher risk groups.

I'm a donor and where I live you can't donate blood if you've received blood (inter-species tissue exchange), lived in UK in the 90s (mad cow disease risk), were born in sub-Saharan Africa (HIV risk) and a couple of others. This includes ever having had male/male sex (very high risk group). Ever been paid for sex? Out. Ever exchanged drugs for sex? Out. The list goes on and on.

The 'in the last 12 months' items are again a form of risk management (they include new partners, tattoos, piercings, infections, illness, surgery, travel to risk countries, etc).

All blood gets tested and though false negatives are still possible, most infections are statistically close enough to 100% detectable after 6 months.

Where I live it's also illegal to sell parts of your body (which includes your blood). The idea behind that is that legalizing this would create a predatory market between people with money and those on the bottom rung of the ladder (poor, addicted, high-risk, all of the above). That's not a hard sell, but it also acts as a filter in the blood donation system. People who are most likely to sell blood are the people you don't want giving blood in the first place.

A detail in my country is that the donation forms don't ask about your sexual orientation, which is irrelevant. If you identify as homosexual (male/male or female/female) but have never had male/male sex, you're good to go.

Blood donation is a region where you're just harshly subjected to selection based on statistics which place you in one risk group or another. Discrimination doesn't factor into it.

This is a preview article that isn't even 2 paragraphs long and requires subscription to read the whole thing. How did this make the front page?

I run FF on linux for dev work (not on FF itself, but for JS heavy web apps). Actually, I run a whole bunch of different FF versions with different profiles for testing a huge variety of things.

My main gripe is that some of the extensions (NoScript, Firebug and friends) sometimes break things, hog the CPU in one way or another or just plain eat up the heap.

I am fine with this. These are extensions, after all and it's for dev stuff, which I judge by a slightly different standard than 'normal user' stuff.

The latest FF releases especially make me happy because they're adding modern web features and working on UX and performance. And it shows and feels.

I don't care about bookmarks because I don't bother storing those in the browser anymore. Was the choice for storing 'stuff' in SQLite a good one? Yes of course it was. It's the best cross-platform way to store structured data on disk, which is why everybody and his/her dog has made the same choice. Are there inefficient ways in which it is being used? Maybe. Probably? I haven't looked into this, but this is hardly an insurmountable problem.

Sure it felt like FF was lagging behind once the WebKit browsers started coming out (with better JS engines) but the Mozilla Team is back in the game with its new release cycles and updates.

And this makes me very happy.

I recently started coding Obj-C in XCode and was very surprised that it's far less polished than what you expect from an Apple experience. That is mostly because an Apple experience is consumer-facing and much more time goes into making that a better experience.

XCode feels like a GUI for GCC, which it is. It's a whole pile of flags that you can set, tweak, etc. If you don't have some GCC experience, this is a bit of a hurdle. Project settings sometimes break (especially around code-signing), so keep your text editor handy. When things break the error messages can be cryptic and there's usually no 'double-click to get to the error in the IDE'. Obj-C is obviously C, but it's also obviously not and also not syntactically similar to, say, C# or Java (or Ruby, JavaScript, Python, etc). I found the step to Obj-C to be fairly trivial, but I thank time spent with C, GCC and Makefiles for that.

After this it's mostly the same as anything else - which is diving into massive amounts of APIs and best-practices.

iphoneos-simulator is brilliant. Much, much better to work with than Android simulators (mostly because of the insanely faster startup time and the ability to change hardware on the fly). Another brilliant piece to find was Instruments, which is an Apple GUI for DTrace. Profiling and tracing execution on simulators and devices is a breeze.

I think memory management is a bit of a non-issue and I'm surprised that's even being brought up. That many programmers only know one language / IDE and judge everything else as inferior/bad/etc is a reasonable observation (if not a totally obvious one), but that's not going to change anytime soon.

TL;DR

    - XCode has warts
    - Obj-C is different than Java/C#
    - Errors can be a pain
    - iphoneos-simulator is brilliant
    - Instruments is fantastic
    - Easy to pick up if you're familiar with GCC

My guess is yes, they do.

If you read a bit deeper into their announcements you'll notice that this is not just 'the government taking over'. The breach post-mortem was handled by a private sector security company (Fox IT) and the SSL cert management was moved to another private sector firm (Getronics). Judging by the announcements this was overseen by the Ministry of Security and Justice, which has its own well-funded divisions of security specialists.

The Dutch government sees digital infrastructure as crucial and invests a lot of time and money into it. Components such as PKI government, etc are initiated by the government but then sourced to the private sector (a fairly common practice). This allows the government to revoke contracts or otherwise intervene if the contractor is in breach of something (bad management, bad governance, failure to comply with security standards, failing audits, etc). I'm guessing that this is also the legal basis for taking over operations from DigiNotar at such short notice.

Also, the Dutch government is a world-class player in the eavesdropping, interception, wiretapping and traffic monitoring game. That implies at least a basic in-house competency in network and crypto matters.

> [..] it is a sure way of getting employment especially if one is studying a field in which employment is scarce outside of academia, say, philosophy.

Just a random observation, but having philosophers with an educational background teaching kindergarten is probably not such a bad thing.

I've done my share of cleanups in various languages. I don't agree that Rails code is "a special kind of horrible", but there are a few things that seem to be very common in Rails code. A lot of it seems to be written by inexperienced programmers.

There are any number of indications for making such an observation.

- Multiple different 'Rails best practices'

Rails has changed a lot since version 1.0, but most of the 1.0 stuff still works. People usually learn Rails by reading blog posts and then trying out what they read. As they write code, read more, etc their perception of what the 'best practice' is changes and so does the new code that they write. This makes a mess of things. Experienced programmers will set a 'best practice' for the entire codebase and if that changes for whatever reason will refactor the entire codebase to match the new standard. This is pretty trivial in Rails simply because the codebase of even huge Rails apps is still pretty small.

- Lack of tests

A lack of tests is considered a sin in the Ruby world, but it happens all the time. Embracing testing, I think, is something that comes with time because if you're new you simply don't see the value of it. Lack of testing is bad, but there are also variations on this rampant in the Rails world. Different test frameworks in a single project (I call this the 'follow-the-shiny-new-trend' problem) or simply boilerplate tests that don't really tell you anything other than, yes, this ActiveRecord object without callbacks can be committed to the DB.

- Breaking MVC

This drives me nuts. Doing Model work in the Model except for over here where I do it in the View for whatever reason. This is a clear sign that the programmer doesn't have a good mental model of what's going on and why this is a really bad idea.

- AJAX

Rails embraced JavaScript very early on and is a very fine framework for doing AJAX in. However, doing AJAX is a completely different skillset and most programmers don't have it. Most projects just seem to have various widgets floating around that don't share a common coding or state system. That makes them hard to unify and also means there's a lot of arbitrary XHR calls going into the Rails app (for which there are often 'special case' Controller methods, which don't share a lot of logic with anything else)

- Inconsistent use of the Rails API

This ties into the 'best practices' point, the Rails API is by now pretty big and you have to take the time to study it. New programmers don't usually do this because they don't have a background in programming in frameworks and resort to trial-and-error programming ('hey this works here, let's move on'). Which, BTW, is something that Rails makes very easy.

There are plenty of other things (terrible SQL, custom Ruby code with magic, arbitrary plugins, etc) but those are usually pretty easy to isolate and fix.

The good news is that Rails codebases are generally pretty easy to fix incrementally. Write up a coding standard, start writing useful tests and pick a test framework (really, RSpec is fine) and work from there.

Hard points to manage (which should be obvious and not Rails-specific),

  - If you're fixing an app that is under active development you have a lot of coordination to do
  - This is easier if you can work on-site
  - It's a lot easier if the dev team is small

That's a good thing, right?

Journalism nitpick : Israel is in Western Asia. Just because they compete in the (shudder) Eurovision Song Contest doesn't mean Israel is in Europe.

    > [...] they accidentally infringe on a patent 

Patents in the software industry were historically held for defensive purposes. If you get large enough you start building a patent portfolio so other companies can't sue you because you'll sue them back. Everybody infringes on everybody else's absurd patents so suing is a Mutually Assured Destruction scenario (neither party wins and the lawyers take all the money that you could have invested in something worthwhile).

Companies like Lodsys and Intellectual Ventures are different. They only have patents and they have no product. So if they sue you for patent infringement you can't sue back even if you have patents because they don't have a product and by definition can't infringe on your patents (if you have them).

Patent fights between corporations are ugly enough, but are generally on a more-or-less level playing field. They happen in the courts between very well funded armies of lawyers.

Suits between, say, Lodsys (money + patents + lawyers + no product) and independent developers (no money + no patents + no lawyers + product) are so vastly uneven and unfair that most developers will just give up before this ever comes before a court. Even if you want to do it on principle it'll bankrupt your life. Just giving up and finding safer markets with (maybe) lower profit margins seems like the obvious way to go for anybody.

Following people implies at least a very basic interest in what they have to say. You can't follow more than a few hundred people and still keep track of what they're saying (and that's with a low average post count). If you're following thousands you're either a bot or just racking up numbers in which case the follow relationship is totally meaningless.

What always surprises me about lists like this is that there are people who follow thousands of others and they still get taken seriously.

The Internet was alive and well before the web came along. It was certainly a different beast at the time but the author is spot-on when observing that the distributed, anarchic nature of ARPANET lies at its foundation.

There is also an alternate scenario that might be interesting to speculate about. Before wide-spread internet availability a lot of people were connecting to (mostly) privately run BBSes. Inter-BBS networks like FIDONET were developed for passing email between FIDONET nodes with gateways into other systems (including, IIRC the internet).

In a world without ARPNET based internet it's not hard to imagine commercial services being built around this. Given enough volume these services would start setting up dedicated links to each other. Enough services start doing this and it makes sense to set up exchange points. All these services rely on the same protocol to communicate over exchange points and that would make proprietary protocol changes difficult so a more-or-less open engineering consortium would be the next logical step to push such changes. Real time communication over this network would be a real commercial selling point (hello chat systems!) so next thing you know you have 'special' emails with high priority and some extra flags that don't end up in email boxes but are sent to end-user programs that only send and receive the 'special' emails. (Hey there protocol selection!).

This wouldn't get us the web any time soon (this kind of network wouldn't have room for arbitrary data floating around), but market forces + social momentum could conceivably build an alternative version of a global data communication network.

> Another option would be for me to learn about data structures and algorithms

I wouldn't call this an option, but it also doesn't mean you have to spend the next year doing nothing but this. I would recommend spending a few days getting the basics under your belt and figuring out the more advanced stuff when you encounter it (and trust me - you will, they're everywhere).

You already understand how apps work and how you build them so if you're unsure what project to tackle next I'd highly recommend picking up Django (because you already know python) and building some web app that just seems interesting to you. It'll give you some server-side experience, expose you to databases and the HTTP protocol (which everyone on the web should know - it's not that complicated but having worked with it really gives you a different picture of the web).

It'll also give you a working knowledge of browsers, AJAX, HTML5, etc which are always useful skills to have. You might even find yourself going back to apps this way by using Phonegap which allows you to write cross-device apps using web technologies (though the process isn't as easy as the website makes it appear).

Basically just work on expanding your knowledge until you find a project that fits and then dive deep into that.

Also, it's all hard work and everybody faces those problems, don't let it get you down.

I'm not a chemist, but from what I recall natural rubber is subject to (relatively) rapid corrosion by ozone and synthetic rubbers don't have this problem. The rubber used for tires on planes and cars is synthetic.

I don't feel like doing the research right now but obviously 'rubber' is an umbrella term if natural and synthetic rubbers have different properties.

Yes, yes, yes, yes and yes.

Learning about these domains allows you to talk to people in them. That allows you to educate people outside of the development group on the specifics of the product and get valuable feedback from them. This allows you to make a better product and at the same time gives you a foundation for doing Biz Dev.

Design is a bit different, but yes - learn the basics of that too and treat designers and design work as development unless your business plan is cranking out logos and t-shirts.

Welcome to unix. Enjoy your stay!