Vector – Open-source Rust utility for logs, metrics and events - <AUTHOR> https://vector.dev/ <comment><USER2> Perhaps unrelated, but I appreciate the honest performance comparison graphs on this website. Instead of just showcasing how much better this piece of software is, it also clearly shows that there are cases where its competitors are performing better.

Moet product pages I've seen just want to sell you their product, telling you all about how it's better than everyone else. With graphs like these, I find the product page to be a lot more representative and reliable than other sales pages.

I wish more software developers would do this.

<comment><USER3> Seems to be really sweet in regards to memory which is one thing that kills me about Logstash / ELK in general. I may have to further evaluate this one as a sane alternative. The one nice thing that ELK has is Kibana though. Wonder how I can generate decent dashboards for this. Would also love to see a database option that is a little smarter. If ElasticSearch crashes or anything it becomes inaccessible for a minute. We lost log data due to instability in ElasticSearch.

<comment><USER4> [https://github.com/timberio/vector/pull/693](https://github.com/timberio/vector/pull/693)

<comment><USER3> Nice, although ClickHouse seems to be a Yandex project. Not sure my boss would appreciate ClickHouse, wonder how does this compare to ElasticSearch though? I'm not looking for 8GB of RAM is not something I can sell my manager.

<comment><USER5> Check out Altinity - this is US based Clickhouse vendor if your boss needs commercial support and less ties to Russia

</comment></comment></comment></comment></comment><comment><USER6> Slightly unfortunate naming, as there is already a Vector project in the metrics space.

[http://getvector.io/](http://getvector.io/)

<comment><USER7> It seems to be somewhat of a trend to prepend or somehow integrate the language used in naming schemes to ensure you have a somewhat unique name, something like "rvector" would at least make this a lot more searchable, because I suspect most people would search for something like "vector rust" with some additions anyway when looking for this.

<comment><USER8> The problem with searching "vector rust" is that vectors are one of the most commonly used data structures in Rust and right now searching that will pull up lots of info on Rust vectors (the data structure), not this project

</comment></comment></comment><comment><USER9> A nice discussion here 2 months ago: [https://news.ycombinator.com/item?id=20334779](https://news.ycombinator.com/item?id=20334779)

</comment><comment><USER10> That's a nice list of sinks and I see the v0.5 Kafka source is already done a few days ago.

1) is there any talk of breaking changes on the road to 1.0?

2) are there any articles about lessons learned from the Timber folks about running Vector at scale?

<comment><USER11> Hey Lemmox, good questions:

1) Not currently, but it's certainly possible. We don't foresee any major fundamental changes. The most likely change is around transforming. Specifically, how you shape both log and metrics data structures. Right now it's a little too piecemeal and we hope to provide ways to consolidate that more. For example, we have a transform for adding, removing, renaming, and coercing fields. We'll probably introduce a single transform to support that or think about ways to support schemas. 2) Yep! We're organizing our content and education strategy to start sharing this information. Expect to see high- quality guides, blog posts, and comparisons in the next 6-12 months.

Hope that helps!

</comment></comment><comment><USER12> Terrible name choice...

</comment><comment><USER13> No comparison with Flowgger? [https://github.com/awslabs/flowgger](https://github.com/awslabs/flowgger)

</comment><comment><USER14> Impressive! I've been using Fluentd a lot, will look at this.

p.s. Search for "complaince" and fix the typo :-)

</comment><comment><USER15> Does timber use Elixir for their ingestion pipeline?

</comment><comment><USER16> Of all the things to name a project these people named it after the most commonly used data structure.

<comment><USER17> Or one of the most common mathematical terms in programming.</comment></comment>


Mark Shuttleworth on the interest rate cut - <AUTHOR> http://www.markshuttleworth.com/archives/139

<comment><USER2> I thought interest rates should rise, that way people would start putting money back into the dollar. We are still at a point where people are undecided what is better long term the Euro or the Dollar. This is going to drag the dollar so low when it perks back up people may not switch back out of the Euro.</comment>


The Rise of the Software Apprenticeship Academy - <AUTHOR> http://bostinno.com/channels/the-rise-of-the-software-apprenticeship-academy/

<comment><USER2> Is there some sweet spot for a developer with ~1-3 years of industry experience? Most of these programs note that all you need is basic programming knowledge - but is there anything out there for 'junior developers on the rise' that are already learning and advancing but want to turbocharge or learn under the leaders in the industry?

It's probably a lame excuse, but it's hard to trade in a steady paycheck for six months of either paying tuition or going back to living on a student stipend.

I _really_ like the apprenticeship model but I feel like the logistics don't work out for anyone that isn't looking to get into programming for the first time or just graduated college.

<comment><USER3> If you have a good base of the right skills, I'd bet that some of theses "learning and teaching" organizations (like ours, RoleModel) would be interested in talking to you about a Jr. position and you'd get much of the same training. You may or may not have to take a pay cut for a little while.

If you don't already have the right skills, my guess is that most of these programs will still work for you. It's up to you about the financial issues. It never ceases to amaze me how poor the practices of many environments are, so not sure what 1-3 years means.

</comment></comment><comment><USER4> I have often wondered at the lack of apprenticeship programs in our industry. We use unpaid interns at my day job and they basically sit on the other side of the building do whatever odd jobs management can come up for them to work on, instead of actually learning the specifics of what we do. The one intern that we ended up hiring full time has slowly started working towards picking up development skills, but it's definitely secondary to his other duties, even though it would benefit the agency considerably if we could get him up to speed.

I understand companies don't want to invest in people if they are just going to leave, but on the other hand they spend so much money trying to find good talent. I suppose you would have to take steps once they are up to speed to make sure you're paying them enough to keep them around. If I knew that a company had really invested in me and gotten me to where I am, I would be more willing to stick around, certainly more so than for a company who hasn't really invested in me (conferences, bootcamps, books, etc).

<comment><USER5> In my opinion the problem you're describing (people leaving after getting up to speed) has more to do with the HR department controlling salaries. If you get a bit of experience under your belt, and get good at what you do, you've got to switch companies to get a raise that reflects your new level of expertise.

There are some companies that will raise your compensation to reflect your experience, but most won't. And that's the problem.

On the other hand, not training your team costs a whole lot more! Shipping junk products can tank your company outright.

</comment></comment><comment><USER6> I'm curious what sort of success people are having getting hired after going through one of these. Without knowing much about them, these feel a little bit like the ITT tech of the startup world. Sometimes CS degrees rightfully get criticized but I'd much rather have someone who went through the rigor of CS fundamentals who can apply those fundamentals to whatever technology rather than someone who went through what I assume boils down to a very in depth HTML, CSS, Ruby tutorial.

<comment><USER5> For full disclosure, I work at RoleModel, one of the companies mentioned... but I think the intention of all the academies is to be a lot more than targeted, long-term tutorials. They'll provide a lot of the same information you'd get from a CS degree, but in the context of a real-world projects instead of classroom problems. And they'll provide a lot of the information you ~didn't~ get in that CS program. Like real world software practices, current tooling, and so on.

Yesterday we had a junior team member run into a problem with a data structure, so that led to an off the cuff tutorial on data structures (linked lists, hash tables, benefits, trade offs, etc) for several team members, but in the context of the current project. And wasn't a part of the academy, just how we mentor our team. We've found that kind of "in context learning" is much more effective than many classroom environments.

I'm not sure how far back the idea goes, but I've only seen it recently, so I'm not sure what you'll find in terms of formal employment rates. However the RoleModel program is lining up sponsors. A "sponsor", among other things, gets first crack at interviewing the graduates. <http://craftsmanshipacademy.com/sponsor/> But I must say, I don't think you'll find Ruby a bad skillset to have. <http://news.ycombinator.com/item?id=3404616>

I strongly suspect these programs are just the beginning of the backlash against what many are calling the higher education bubble. People are tired of graduating thousands (or tens of thousands!) of dollars in debt after investing years of their life. These programs compress down the process, and eliminate a lot of the non-core learning, to help you become productive as quickly as possible.

I have a CS degree, but have seen and worked with a number of the people that have come through the RoleModel mentoring program in past years. I think the academy concept is a more formal iteration of that same idea. I'm looking forward to our first class in a few months.

<comment> UK-Al05 Do you teach 'hardcore' cs? Like the master method for working out big O? That's is what I think he is trying to say people might be missing.

There are plenty of tutorials on the internet about data structures, relatively few about algorithm analysis.

<comment><USER5> Big O came up yesterday, but you're right... we didn't go that deep. There are some jobs where you'll want that depth of background, but in my career they've been rare. At the end of the day it's about finding the right fit for yourself. This type of training will suit some, but not others.

</comment></comment></comment></comment><comment><USER7> It's a bit dissapointing to me that they are all focusing on web technologies/development. I know, we're at HN and webapps are popular, but still... Are there any with a different focus? Drivers, firmware, OSS development? (Dislaimer: currently doing web and GIS development, perhaps I'm getting a little bored?)

I'm asking out of curiosity, being only 2.5 years out of college with a BS in CS.

<comment><USER5> I think they're just scratching the itch they have... a lack of those skill sets. If it catches on, I'm sure other companies will give it a try as well.

I have found the embedded industry to be a tad more conservative (That was an understatement. ;) ), so it may be a bit longer before they pick up the model.</comment></comment>


Tesla announces new Model 3 production plans - <AUTHOR> http://electrek.co/2016/05/04/tesla-tsla-surge-model-3-production/ <comment><USER3> I hope they hit it, but they've had manufacturing issues in the past. In fact they've never hit a target release date yet, 6 months late is the best they've done. Now this could be that:

\- they are just really optimistic on their release dates,

\- they announce early to try and cut off competitors sales

\- they just aren't that good at manufacturing ramp up.

Just last night they were forced to join a recall due to faulty air bags from a supplier, Takata Corp. They've got alot of things that need to happen for this to occur.

-They can't have any unforeseen issues op recalls crop up with the Model S or Model X.

\- They battery factory has to come online without a hitch.

\- The price of lithium and other rare earth minerals has to remain steady, I've heard that its very hard to hedge these prices due to a lack of counterparties willing to take on the risk

\- their rumored/china manufacturing plant has to come online smoothly

\- and off course they need to be able to ramp up manufacturing on a car they've never produced

One side effect of this is that this means that US tax credits for EV cars would start to taper off at the beginning of 2018 and fully end at mid 2019 for all electric vehicles.

I can't pin down any analysts on a consensus as to whether or not they'll hit their manufacturing target for either the first model 3 delivered or the 2018 500,000 cars manufactured.

The only consensus I could get is that if they need more cash to make it happen they'll have no problem tapping the credit or equity markets, regardless of the conditions at the time. The markets seem to really want this to happen, which is awesome.

Minor note on the story, Its true that TSLA moved up slightly in the after hours but its actually now well down from yesterday's close.

<comment><USER4> >-They can't have any unforeseen issues op recalls crop up with the Model S or Model X.

This is a service issue, not production. Tesla has weathered recalls before. Of course an expensive major recall could delay their capex investment, but it's in no way true that _any_ unforeseen issues will cause a delay.

>\- They battery factory has to come online without a hitch.

The factory is already online. It will have to ramp production, and accordingly it's a major focus for the company.

>\- The price of lithium and other rare earth minerals has to remain steady, I've heard that its very hard to hedge these prices due to a lack of counterparties willing to take on the risk

Lithium is not a rare earth metal, nor are any rare earth metals used in Tesla batteries. The price of lithium makes up a tiny percentage of the overall battery cost -- nickel and cobalt are both more significant cost drivers.

>\- their rumored/china manufacturing plant has to come online smoothly

Not needed. Fremont can deliver 500,000 cars/year on its own.

>\- and off course they need to be able to ramp up manufacturing on a car they've never produced

Which is why this is Tesla's other main focus.

The same can be said of any new product. _Everything ever produced_ was "never produced"... until it was.

So... 2/5.

</comment></comment><comment><USER5> Is there any new technology in the 3 that wasn't already shipped in the S or the X? Call me crazy, but I don't think the 3 will give them the production headaches that the S or X gave them.

<comment><USER6> The price of the Model 3 relies on using economies of scale to make it cheaper to manufacture. But the saving are projected, not guaranteed. Also, they need to make many more of them per year, which is not trivial.

</comment></comment><comment><USER7> A factory capable of producing over 1000 cars per day is truly staggering.

When I was living in the Midwest, the traffic lights were synced to the local GM plant's shift schedule because the volume of employees driving in made it look like traffic to a theme park. Does Tesla's factory do something similar?

<comment><USER8> I was disappointed that there is no live traffic view available around the Gigafactory [0], but filled with joy to see that its access road is named Electric Avenue.

Previous reports seem to indicate that the workers may be at the factory for 20 hours a day, so perhaps they're all sleeping next to Elon in burlap sacks to cut down on congestion?

[0] [https://email@example.com,-119.4397724,14.46z/...](https://email@example.com,-119.4397724,14.46z/data=!5m1!1e1)

<comment><USER9> You might also enjoy Letsby Avenue in Sheffield, home of the South Yorkshire Police Operations Complex.

[https://www.google.com/maps/place/Letsby+Ave,+Sheffield,+Sou...](https://www.google.com/maps/place/Letsby+Ave,+Sheffield,+South+Yorkshire+S9,+email@example.com,-1.400877,17z/data=!3m1!4b1!4m5!3m4!1s0x487977c3772a9353:0xa4b1e940b7ae6f81!8m2!3d53.395609!4d-1.3986883)

<comment><USER10> I didn't get it. That's apparently a very British joke.

Explanation for anyone similarly baffled:

[http://forum.wordreference.com/threads/999-letsby- avenue.147...](http://forum.wordreference.com/threads/999-letsby- avenue.1476317/)

</comment></comment></comment></comment><comment><USER11> Its all good, but can Tesla deliver?

They were late with the Model X, and they're currently losing $280 million per quarter or so with only 1.4 Billion in cash remaining (a lot of it probably tied up in other short-term liabilities). And that was with 500k cars by 2020 as the plan. (Tesla has a few lines of credit that they can tap between now and then... but you can tell that the money is going to be tight)

If Tesla is accelerating plans, we can expect them to burn through even more money as they ramp up production even harder. It will be worth it of course, but this isn't an easy path for them to take. I'd expect that Tesla will need another stock offering to raise enough funds.

<comment><USER12> With such massive interest in the Model 3, raising funds shouldn't be hard. "We need money to fulfill a massive backlog of reservations" should be an easy sell.

Their ability to deliver, irrespective of cash, is definitely a big question. Hopefully they have learned the right lessons from the problems with the X and won't repeat it. I think this is likely, but it remains to be seen.

<comment><USER11> > With such massive interest in the Model 3, raising funds shouldn't be hard. > "We need money to fulfill a massive backlog of reservations" should be an > easy sell.

[http://ir.teslamotors.com/secfiling.cfm?filingID=1193125-16-...](http://ir.teslamotors.com/secfiling.cfm?filingID=1193125-16-577582&CIK=1318605)

Tesla has $1.4 Billion in "Accounts Payable and Accrued Liabilities" and $1.4 Billion in Cash (or cash-equivalents), and are losing $280 Million PER QUARTER, with 2017 as the soonest launch date for the Model 3.

Note that Tesla's R&D efforts are only $182 Million, so Tesla is losing $100 Million per quarter even if they cut all R&D efforts off entirely!

Now I know that a lot of Tesla's accounting is weird: I think the Model 3 ramp-up effort might not actually count as R&D (although this is from memory). But... this isn't exactly the healthiest balance sheet that I've seen. There's a good chance that Tesla is simply going to run out of money entirely before 2017 unless it can secure even more long-term loans or raise capital somehow.

And if you're a company that is threatening to die, then banks will not want to lend more money. No matter the wild promises of future revenue you may bring to the table. Elon Musk managed to get a $300+ million "loan" from the preorder program (its sort of like a loan, without any interest. Good job Elon on selling that preorder stuff!). But Musk will have to repeat this feat every quarter until his company starts making money.

Or, he needs to fix this company to start losing less than $280 Million per quarter. That's... a serious, serious problem.

<comment><USER13> >Or, he needs to fix this company to start losing less than $280 Million per quarter. That's... a serious, serious problem.

The fix is to sell lots and lots of Model 3s.

In terms of raising money... 400,000 people put down a grand to reserve a Model 3. That alone covers the gap for 4-5 months and costs nothing.

<comment><USER11> Yeah.

Now Tesla needs to raise that amount of money repeatedly until they stop burning money (which probably won't happen until the Model 3 is released). I tend to think that this $400M or so that they got is a one-time thing. Its not like they can suddenly announce a Model 2 and get another $400 Million from the public.

</comment></comment></comment></comment></comment><comment><USER14> Well, now we know why their production chief quit.

</comment><comment><USER15> I think we know some stuff about Tesla's products, their stock, their leader, but we know much less about their manufacturing issues. In a way it is not a bad problem to have that they can't scale up too well, if that's their only problem. Imagine if they figure this one out! One would think they are hiring aggressively from GM and the like, so they will eventually have enough domain experts who will make a difference and build a solid manufacturing potential. Or does anyone have a good analysis about the manufacturing side? Details and insight, I mean.

</comment><comment><USER16> Volvo just announced that they sold 120 000 cars in this years first quarter. Can Tesla sell more of one model than all of Volvo's models combined? Tesla has vocal proponents in the rich tech community, but can they translate that to the mass market?

<comment><USER17> Tesla's margins per-vehicle tend to be much much higher than Volvo's as well. Volvo is the biggest car manufacturer in the world, just barely beating Toyota. So comparing the biggest of the entrenched companies against a fledgling startup which is just starting to hit it's stride is disingenuous at best.

<comment><USER18> Volvo is nowhere near the largest car manufacturer in the world. You are probably thinking of Volkswagen.

<comment><USER17> Oh wow, lysdexia fail. Good point, thanks!

</comment></comment></comment></comment><comment><USER19> Curious if it's better to purchase an existing plant (and presumably upgrade), formulate a new one, or just extend their existing plant to reach this goal.

Sounds a lot like software dev (buy, rewrite, or build on top of...)

<comment><USER14> They're in the old GM Fremont plant, later NUMMI, a joint venture with Toyota. But that just gets them big empty buildings.

</comment></comment><comment><USER20> I wonder if Elon Musk will receive death threats one day, or if oil companies will try to mess with anything that deal with Tesla.

For example, I wonder, is it possible for an entity to "take over" the lithium mining industry that is outside the US?

<comment><USER15> But from the oil companies' perspective, Tesla is pretty small!

<comment><USER15> I think a typical oil company/country does not keep Tesla high on the agenda. They probably worry about Russia, policy changes of USA, wars around them and global economic stability. Tesla started - or contributed a lot to - <USER2> revolution that they should worry about in the long run, but they have a different perspective than a Tesla enthusiasts like myself.</comment></comment></comment>


UPS is working on a fleet of 50 custom-built electric delivery trucks - <AUTHOR> https://techcrunch.com/2018/02/22/ups-is-working-on-a-fleet-of-50-custom-built-electric-delivery-trucks/?ncid=rss&utm_source=tctwreshare&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29&sr_share=twitter <comment><USER2> [https://news.ycombinator.com/item?id=16439246](https://news.ycombinator.com/item?id=16439246)

130+ points</comment>


How I Write Tests - <AUTHOR> https://blog.nelhage.com/2016/12/how-i-test/ <comment><USER2> Excellent article and it's perfect timing for me!

In the past while contracting I was usually asked to include in my proposals estimates for tests.

The tests failed to be useful, simply because they were written _after_ the feature was actually implemented! We knew better, of course, but this was done in order to quickly get builds a client could look at.

Then when clients wanted to add/change features guess what got cut to make up for the time? Thats right, the tests!

So the tests were always secondary, and the projects tended to suffer as a result.

Recurring "fixed bugs" cost more than just working hours to fix. In the eyes of a client or customer, they are so much worse than a shiny new bug. Tests can help catch recurring bugs _before_ a client/customer does - and save you not only time, but from losing your customers confidence.

Now, I'm building my own app and I'm using a diciplined TDD approach. I didn't start my project this way as It seemed overkill when it was just me. But I saw early on that to not practice TDD even solo was madness. It _is_ taking longer, but my actual progress is consistent, and I'm already far more confident about the stability of the app.

<comment><USER3> > The tests failed to be useful, simply because they were written after the > feature was actually implemented!

I find after-the-fact asserts, unit tests, and static analysis still useful:

\- I catch incorrectly handled edge cases that I haven't hit "in the wild" yet (although others may have!) \- I think of new edge cases to handle \- I can be more aggressive in future refactoring \- I can be more confident in excluding the code from my bug hunts

Many of the issues I catch this way are the kind of issues that threaten to turn into really nasty heisenbugs - such as the occasional missing mutex lock. After all, all the low hanging fruit was probably caught when testing the feature locally ;)

<comment><USER4> Parent is talking about functional test cases, i.e. something that can be tested manually from command line. Unit tests are not a functional or integrational tests, so yes, unit tests are useful even after functional and integrational tests are written.

<comment><USER5> The concept of a functional test seems to vary quite a bit more from engineering group to group than your usage indicates.

Sometimes, some unit tests border on functional tests and vice versa, the distinction blurring between two adjacent test cases in a unit test suite.

And sometimes integration suites end up testing single functionalities at a time, depending on the design and/or requirements of the application, and could reasonably be called functional tests.

On my team, I hesitate to emphasize "functional tests" as a standalone group equivalent in semantic distinction to unit and integration tests; the proper scope of a "functional" test is defined, to me, by the way the functionalities of an application were designed and decoupled, which depends on the particular project.

(If your organization uses functional requirements and specifications for software design, it's simpler - a functional test verifies a functional requirement. Unfortunately, having functional requirements as a part of the engineering process is significantly rarer than it should be.)

</comment></comment></comment></comment><comment><USER6> Interesting post. I have found myself doing a lot of the same things through my own experience. One thing I have been striving for lately is to build functionality using relatively more small methods that accept paramters as opposed to using state which is stored in instance variables. I find that this makes my life easier when writing tests and also helps identify corner and edge cases that I may not have thought about. And when something does break it is usually very easy to add a failing test, fix the code, and see that everything is now working. Also makes me a lot more confident when I go to refactor. Sandi Metz gave a great talk on the gilded rose problem that explores these concepts.

<comment><USER7> How do you avoid the parameters from getting bloated? Like having to pass the same dependencies into every method.

<comment><USER6> It's a judgement call to be sure. If I start seeing a pattern of adding a bunch of parameters I stop and rethink what I am doing. Usually there is a structural problem that can be fixed.

</comment></comment></comment><comment><USER8> > My final, and perhaps more important, advice is to always write regression > tests. Encode every single bug you find as a test, to ensure that you'll > notice if you ever encounter it again.

This is a nice ideal but in practice can be really hard. For example, say I fix a grammar mistake in a text label (or, hard mode, a code comment). One could write a test, perhaps integrating a grammar checker, but this is a lot of work, for a low reward. So where do we draw the line?

It's easy to test things that have inputs and output representable as binary blobs. It's hard to test that this animation is smooth, that the build succeeds on obscure systems, that this graphic is rendered acceptably, that this event happens when the user connects that device. Or, rather, it's easy for a person to manually test any of these things, but hard to write an automated test for them.

A common failure mode is to capture the input and thereby isolate the system. If 95% of your bugs are due to interactions with your dependencies, isolating your system is going to find very little compared to a full integration test. This is a great way to make the tests pass, and also make the tests useless.

Maybe we conceptualize testing on two axes: automated testability and manual testability. If you try to write tests for components that have poor automated testability, you'll hit a valley of pain: spurious failures, excessive mocking of your dependencies, etc., that you can only climb out of with great effort (e.g. a robot inserts an HDMI cable). If these components have good manual testability, then it may be more cost effective to just test it manually.

</comment><comment><USER9> >My final, and perhaps more important, advice is to always write regression tests. Encode every single bug you find as a test, to ensure that you'll notice if you ever encounter it again.

This is good advice.

On a previous (technical-debt ridden) project I did a little measuring and there was a pretty clear hierarchy of test value - in terms of detected regressions:

1) Tests written to invoke bugs.

2) Tests written before implementing the feature which makes them pass.

3) Tests written to cover "surprise" features (i.e. features written by a previous team that I never noticed existed until they broke or I spotted evidence of them in the code).

4) Tests written after implementing the feature.

5) Tests written just for the sake of increasing coverage.

Surprisingly 5 actually ended up being counter-productive most of the time - those tests detected very few bugs but still had a maintenance and runtime overhead.

<comment><USER10> What do people think about writing explicit regression tests for bugs found through fuzz testing? I've tended to lean towards not writing them, depending on continuing fuzz testing to insure things stay clean. This may of course be somewhat naive, but I also fear cluttering my test suite with really obscure test cases.

<comment><USER5> I think the premise of your question confuses considerations, unless I've misunderstood.

On all projects I own, the policy is that a bug fix will not be merged into a codebase without comprehensive unit testing demonstrating the case in which that bug was discovered, and that it has been resolved.

I do not understand why it matters _how_ the bug was discovered. If fuzz testing discovered that function foo throws tries to dereference a null pointer given input "ABABAB", then I would expect the engineer who chose to address that bug to investigate what property of "ABABAB" is the unaccounted for property, account for it, and then write a unit test calling foo with input "ABABAB", along with several other inputs that share the same discovered underlying property.

Fuzz testing may be a different method of testing, but the end result is, regardless, that you have discovered an input that your application hasn't been designed to handle properly and that needs to be demonstrably fixed, whatever it may be in particular.

</comment></comment></comment><comment><USER5> This post is timely for me because it happens to encapsulate the way I've found a balance recently between test driven development and "test after writing" development that seems to be very effective for me.

As the article notes, writing all tests first is unreasonable because you won't know all implementation details until you have to make them; the tests I write first are thus functional tests, nowadays with cucumber.

Writing tests after coding is lacking, philosophically, because you often spend your time defining the abstractions and then just rewriting a verification of that abstraction in tests, plus some null checks.

The balance I've been using has been to write tests for abstractions I come up with, one my one. If an abstraction is decoupled and encapsulated, the unit tests come naturally. If i have to write a lot of mocks for an abstraction, that often tells me it isn't cleanly decoupled or simplified.

Furthermore, as you write tests as you go this way, you often find yourself writing the same support code more than once, at which point you notice it and find abstractions in that support code; this ends up explicitly giving you a view of what conscious and subconscious assumptions you have about what inputs you are expecting and what assumptions you have made. This is often enlightening.

</comment><comment><USER11> I don't like to write tests ahead of code, but the idea of "Avoid running main" is very powerful and something that helps me a lot. Usually in a new project I try to just use tests as the playground for the evolving code, and delay actually creating a working application for as long as I can (not so hard in non UI apps). In an existing project you delay integrating your new module with the whole app.

Sometimes my tests just start as a bunch of prints to see the results visually. Then when I'm happy with the results I convert these prints to assertions and the playground becomes a real test suite.

<comment><USER5> It is a nice quote, but frankly I would not want that to be the takeaway. Remembering "Avoid running main" is just a principle without reasoning or justification, past remembering it sounded right when first read.

The underlying concept is that unit tests should verify behavior of minimal units of functional code. If you are running the application, you are testing much more high level functionality. "Running main" and "running unit tests" are completely different things, and I would rather the principle behind this difference be the takeaway, rather than just "avoid running main."

<comment><USER12> The advice really is to avoid the quick dopamine hit of running the app and seeing the new feature work by manual testing.

It's a motivation thing, and I think it can be very valuable tip how to motivate yourself to keep up your unit test suite (for those of us who need this behavioral trick).

</comment></comment></comment><comment><USER13> Nice to see a non religious post about testing.

Particularly enjoyed the emphasis on regressions. I converted to testing when working on a relatively complex data transformation. This was replacing an existing, scary data transformation process that was hard to test (we'd run new code for a few days and do a lot of manual examination), so I made extra certain to design the new system so it was testable. Catching regressions in test, especially for data processing, is just so much better than catching and repairing them in production.

</comment><comment><USER14> > I fully subscribe to the definition of legacy code as "code without an > automated test suite."

> I've never really subscribed to any of the test-driven-development > manifestos or practices that I've encountered.

I feel the exact opposite. I've worked in project with a lot of legacy code, both with BDD or with UTs that we added latter on.

Even with the best intentions the latter always failed: we always ended up doing a lot of unreadable tests that had no meaning and that we were afraid to look at. However, when I was working in a team fully committed on BDD, we were looking at the tests before looking at the code, the tests were in the center of the developing process, and we were able to write fast, solid, and simple tests.

Nowadays, I'm more interested on articles that understand that tests can be a pain too. And tbh I don't really trust articles that aim at a high coverage without talking about the different challenges that comes with tests.

<comment><USER5> This isn't exactly a fair comparison, in my opinion. Legacy code that was written before unit testing had become a habit tends to have a design that isn't always easily covered by unit tests; furthermore, when you give a team of engineers legacy code and ask them to add tests, they have to trace the source, make an interpretation of what they perceive the design considerations to have been, and then write tests to that. What you often end up with, though, is starting by unit testing the easier to understand pieces of code, checking for robustness to some bad inputs, and then somewhat skimping on unit tests on the code that most embodies the original authors' design considerations.

Which, to be fair, is a highly nontrivial task that will realistically never be completed as well as if the original authors had written unit tests demonstrating the intent of their design. And the comparison you should have been making is to that scenario.

</comment></comment><comment><USER15> People into testing everything should also remember there's test generation tools in commercial and FOSS space to reduce work necessary to do this. Here's two examples for LLVM and Java respectively. Including the KLEE PDF since the results in the abstract are pretty amazing.

[https://klee.github.io/](https://klee.github.io/)

[https://www.doc.ic.ac.uk/~cristic/papers/klee- osdi-08.pdf](https://www.doc.ic.ac.uk/~cristic/papers/klee-osdi-08.pdf)

[http://babelfish.arc.nasa.gov/trac/jpf/wiki/projects/jpf- sym...](http://babelfish.arc.nasa.gov/trac/jpf/wiki/projects/jpf-symbc)

</comment><comment><USER16> His comment about the "zoo" of data-driven tests made the way my university's major algorithms class did tests finally make sense. It's not a concept that particularly easy to search for when you're working from the command of "make tests with this filename format, 'test-<args>'", nor is it even something that strikes one as something that might be an actual design pattern (at least for me).

I do wish the reasoning had been explained to me far earlier as I might have been able to really recognize the testing as useful and not just another strange requirement.

<comment><USER5> It occurred to me in response to your comment that, pedagogically, it seems so obvious to tell math students to check their work, yet my universities never even mentioned unit tests (outside, perhaps, of the sole, non-required software engineering course, as I believe it was a work coop type of arrangement).

</comment></comment><comment><USER17> Has anybody experience with testing code that produces graphics (e.g. 3D engines, etc.)? I saw some articles stating that mocking the API is a good approach. But how can you test shaders etc. Tests based on image comparisons seem very cumbersome. We currently rely heavily on our QA which does automated integration tests based on image comparisons. But there is no immediate feedback for developers with this approach.

<comment><USER18> I'm working on a project where I'm doing boolean ops on 3D meshes that need a lot of tests.

I do a mixture of traditional unit tests w/asserts along with visual feedback. I have a rig set up that will dump final (or intermediate) results of operations to the screen with several tests being presented at the same time.

If I'm actively developing something and am going to be spending a lot of time in the debugger I can solo a test. Having the additional visual feedback makes everything go a lot faster.

For higher level stuff having a number of tests on screen at once gives visual feedback about regressions, which again speeds things up a lot.

This combined approach is the most useful I've found so far.

</comment></comment><comment><USER19> Does Linux have a comprehensive test suite (comparable eg. to SQLite)? I'm wondering because it seems to be quite bug free, and is a large project, and a kernel seems to be quite suitable for unit testing (compared to your typical CRUD app for example).

I suspect there's not much formal testing (at least done or required by Linus, some external projects may be available). So it seems that testing isn't that necessary for a quality project? On the other hand Linux has a large community so maybe that substitutes for a comprehensive test suite?

<comment><USER20> There is a separate project for testing Linux : [https://github.com/linux- test-project/ltp](https://github.com/linux-test-project/ltp)

</comment></comment><comment><USER21> These days, I treat test code the same way as I treat application code, refactoring and cleaning up as I go. I've noticed that in most projects, unless you do this, there's a tendency to copy-paste tests, without any thought given to DRY.

<comment><USER22> Going too crazy on non-dry tests can make tests failures hard to track down, though. Meta-programming to generate tests has only lead to pain in my experience.

<comment><USER21> If you're following the red-green-refactor cycle properly, then you'll have seen test failures on DRYed tests. Most testing frameworks let you customize the failure message. It's usually a simple matter of adding more information about which part of it failed.

I won't meta-program for tests, but I will do things like make a list of classes, or symbols or whatever, to pass to a loop. Just keep it simple.

<comment><USER23> > I won't meta-program for tests, but I will do things like make a list of > classes, or symbols or whatever, to pass to a loop. Just keep it simple.

This is a case where metaprogramming for tests came in handy.

I had a bug recently that involved someone making a change that violated an invariant property of a class. To codify this invariant, I was tempted to do what you did, to make a list of symbols to feed into my test to ensure the invariant was obeyed. However this bug was caused precisely by someone adding a new symbol, a method, that didn't obey this property. The test using this design wouldn't catch this failure. I instead opted to do some introspection (it's Python, so it was dead simple) on the class to ensure all of its methods obeyed this invariant. It took a little extra time to implement but in the end it worked.

<comment><USER5> With the caveat that I haven't invested the full amount of time necessary to strongly state this opinion publicly, I do feel that metaprogrammed tests are a case of adding abstraction unnecessarily (which, incidentally, is why I haven't taken the time to try to extensively use them on a project.)

A test should be dead simple to read and understand when someone else new to the project needs to understand what it tests. Further, when a test fails, the output should clearly indicate exactly on what line of code an error occurred.

Metaprogramming tests feels to me like a case of a desire for or predilection for cleverness getting in the way of what the task is actually for.

Tests should tell a story. They should not be subjected to the same methods of abstraction used in the code they themselves are supposed to test and verify.

</comment></comment></comment></comment></comment><comment><USER24> The writing a module and it's tests together, and doing them both at the same time is some of my #1 advice. If you're having to run main while developing, I consider something to be a bit odd.

I also find this a much more favorable approach than pure TDD. In my opinion, This method is easier to "sell" to other developers.

<comment><USER5> My opinion is that TDD can only reasonably be done if you already know what your implementation must be, which is difficult to do unless

* you have already done it, or something sufficiently similar, before; * you have formal functional requirements; or * you have detailed use cases.

Personally, I've recently come to really favor use cases as part of the design process. The mindset behind them requires some effort to learn, but I find them an effective vehicle for categorically separating what an application must do from any consideration for how it might do it.

</comment></comment><comment><USER25> I find that bugs occur when you do not fully understand all possible state combinations and edge cases. So if that is the case I try to break it down to smaller units that are easier to comprehend. There will still be bugs though, but they are usually edge cases you didn't imagine would happen, and that's where I find testing useful, as the next person who touch the code probably will also miss that edge case.

1) Make changes 2) Manually test & run automatic tests 3) Write automatic tests for each problem/bug discovered 4) Repeat

This only works for decoupled code though. If all units are coupled you must have automatic tests of everything as no-one can comprehend exponential complexity.

<comment><USER5> What you are describing is the process of identifying what the "units" are that should be covered by unit tests.

</comment></comment><comment><USER26> I am certainly no religious follower of TDD, but I _do_ think writing tests before code is useful.

The reason is simple: it tests your tests. I have many times found bugs in tests that made them always pass.

<comment><USER27> There is an even better way to test your tests - the mutation testing, for example [http://pitest.org/](http://pitest.org/). It also helps to find dead code, that doesn't have any impact on result any more.

</comment></comment><comment><USER28> One important concept in testing is "code coverage". The technique is to (conceptually) place a unique print statement in every branch of every "IF" statement or loop (every basic block), and then try to write tests until you've triggered all of the print statements.

EDIT: This explains the concept, and gives a _minimal_ approach to testing (i.e., you should test more than this, but at least this). Of course, there are tools to automate this, but not for every (new) language.

<comment><USER29> That doesn't fully test your code. By testing "if a", "if b" separately, you could miss a bug that occurs when a b are both true.

<comment><USER28> > That doesn't fully test your code.

I didn't say that. Be wary of people who say they fully tested your code :)

Anyway, there's another (non-waterproof) approach: try to trigger all possible paths through the code (instead of all basic blocks), but the problem is that the number of paths can increase exponentially with code size.

The code-coverage approach, in contrast, is very cost-effecitve. For example, roughly speaking, it triggers all possible exceptions that your code can throw.

<comment><USER30> > The code-coverage approach, in contrast, is very cost-effecitve. For > example, roughly speaking, it triggers all possible exceptions that your > code can throw.

Well, unless you count uncaught exceptions from things your code calls.

<comment><USER5> Or unless you simply forgot to check all possible invalid inputs - which, all of us being human, will happen periodically, even with code review.

</comment></comment></comment></comment></comment><comment><USER31> I just took a peice of code with quite good test coverage, and stopped running main a couple of times during the "unit" test run. Coverage plumetted, and I realised how much of the code is still untested.

(The code was actually already structured for testing, I just hadn't written them because of that coverage number....)

I am still running main, by the way, but that's a different invocation called "system tests" which runs if unit tests pass (and after the coverage report).

<comment><USER5> This is a prime example of why not to covet code coverage figures. They can never be taken at face value as an indicator of testing quality or comprehensiveness.

Incidentally, OP, I empathize - I had to learn it the hard way too.

</comment></comment><comment><USER5> Having responded to several comments here, I am concerned about the fact that most of the discourse here seems to fail to completely understand what the goals are of unit testing - and, worse, many comments, despite this omission, seem to be made with an air of confidence which I could see myself, when I was a junior developer, accepting as reliable, because of that tone. As of this writing, I feel that anyone new to unit testing that comes across this overall discussion will be sent down the wrong path and may not realize it for a very long time, and so I feel that it is important to outline what I feel are the most serious misconceptions about unit testing I see here.

* Code coverage's value: code coverage is not a goal in and of itself. Seeing 100% code coverage should not make you feel comfortable, as a statistic, that there is adequate testing. If you have 100% coverage of branching, you might have indeed verified that the written code functions as intended in response to at least some possible inputs, but you have not verified that all necessary tests have been written - indeed, you cannot know this from this simple metric. To give a concrete example: if I write one test that tests only a good input to a single function in which I have forgotten a necessary null check, I will have 100% code coverage of that function, but I will not have 100% behavioral coverage - which brings me to the following point.

* What to think about when unit testing a function, or how to conceptualize the purpose of a unit test: unit tests should test behavior of code, so simply writing a unit test that calls a function with good input and verifies that no error is not in the correct spirit of testing. Several unit tests should call the same function, each with various cases of good and bad input - null pointer, empty list, list of bogus values, list of good values, and so on. Some sets of similar inputs reasonably can be grouped into one bigger unit test, given that their assert statements are each on their own line so as to be easily identifiable from error output, but there should nevertheless be a set of unit tests that cover all possible inputs and desired behaviors.

* Unit test scope: A commenter I responded to in another thread had given criticism along the lines of that by making two unit tests which test cases A and B entirely independent, you fail to test the case "A and B". This is a misunderstanding of what the scope of a unit test should be in order to be a good unit test - which, incidentally goes along with misunderstanding the intent of a unit test. A unit test, conceptually, should check that the behavior of one piece of functional code under one specific condition is as intended or expected. The scope of a unit test should be the smallest scope a test can without being trivial; we write unit tests this way so that a code change later that introduces a bug will hopefully not only be caught, but be caught with the most specificity possible - test failures should the engineer a story along the lines of "_this_ code path behaved incorrectly when called with _this_ input, and the error occurs on _this_ line". More complex behavior, of the sort of "if A and B", is an integration test; integration tests are the tool that has been developed to verify more complex behavior. If you find yourself writing a unit test that is testing the interaction of multiple variables, you should pause to consider whether you should not move the code you are writing into an integration test, and write two new, smaller unit tests, each of which verifies behavior of each input independent of another.

* Applying DRY to test setup: if you abstract away test setups, you are working against the express intention of each unit test being able to catch one specific failure case, independently of other tests. Furthermore, you are introducing the possibility of systematic errors in your application in the _very possible_ case of inserting an error in the abstractions you have identified in your test setup! Furthermore, f you find yourself setting up the same test data in many places, that should not suggest to you to abstract away the test setup - to you, it should rather hint at what is likely a poor separation of concerns and/or insufficient decoupling in your software's design. If you are duplicating test code, check whether you have failed to apply the DRY principle in your application's code - don't try to apply it to the test code.

And, in my opinion, the most important and common misconception I see here, and I really feel that it should be more widely understood - and, in fact, that many problems with legacy code will likely largely stop occurring if this mindset becomes widespread:

* Why do we write unit tests?

We write unit tests to verify the behavior of written code with respect to various inputs, yes. But that is only the mechanics of writing unit tests, and I fear that that is what most people think is the sole function of unit tests; behind the mechanics of a method there should be a philosophy, and there is.

Unit tests actually serve a potentially (subjectively, I would say "perhaps almost always") far more vital purpose, in the long term: when an engineer writes unit tests to verify behavior of the code he has written, he is, in fact, writing down an explicit demonstration what he intended the program to _do_; that is, he is, in a way, leaving a record of the design goals and considerations of the software.

(Slight aside: in my opinion, being a good software engineer does _not_ mean you write a clever solution to a problem and move on forever; rather, it means that you decompose the problem into its simplest useful components and then use those components to implement a solution to the problem at hand whose structure is clear by design and is easy for others to read and understand. It further means (or should mean) that you then implement not only verification of the functionality you had in mind and its robustness to invalid inputs which you cannot guarantee will never arrive, but also implement in such a way that it indicates what your design considerations were but serves as a guard against a change that unknowingly contradicts these considerations as a result of a change made by someone else (or yourself!) at a later time.

Later, when the code must be revisited, altered, or fixed, such unit tests, if well-written, immediately communicate what the intended behavior of the code is, in a way that cannot be as clearly (or even necessarily, almost definitely not immediately) inferred from reading the source code.

In summary, these are the main points that stuck out to me in the conversations here; I do want to emphasize that the last point above is, in my opinion, the most glaring omission here, because it is an overall mindset rather than a particular consideration.

</comment><comment><USER32> I like this article, however, I would emphasise that there is a balance that must be struck between writing mini-DSL/fixture generating code v.s. writing simple data structures (e.g. Object literals that mimic JSON).

Its a good thing to take extra care writing the generating code, as any brittleness is passed onto dependent tests.

</comment><comment><USER33> i think that languages that have a very good REPL make it easier to write tests. Because you play around in the Repl, you automatically write a few tests that you just have to copy. Also, if you design your software repl- friendly, there is a lower overhead for your tests (easier set-up etc.)

</comment><comment><USER34> I avoid running main by testing at compile-time :-).

[https://github.com/billsix/bug/blob/master/demo/src/bug- demo...](https://github.com/billsix/bug/blob/master/demo/src/bug-demo.bug.scm)

</comment><comment><USER35> This is great. It's nice to see an article from someone who doesn't "do" TDD, but also isn't ranting about how tests are useless. I personally use and prefer (test-first) TDD but still agree with all of the advice in this article.</comment>


Create your own portfolio within just 3 minutes - <AUTHOR> https://medium.com/@p32929_77176/create-your-own-portfolio-within-3-minutes-dfc92ddf0b8c <comment><USER2> Nice work, thanks finally can get my personnel site up. Pretty much never have time to complete it, this is usable an quick. Responsive too.

<comment><AUTHOR> Thanks. I really appreciate your comment. Feel free to create your own portfolio or contribute source codes</comment></comment>


Elon Musk faces investor lawsuit - <AUTHOR> https://www.bbc.co.uk/news/business-45155268 <comment><USER2> Did no-one pick up on the proposed price, 420 ?

Maybe he should have settled for 419

<comment><USER3> Curious question: what's wrong with 420$/share ?

<comment><USER4> Well he was going to sell for $69 a share but then he tried $666 a share but that was too high so they settled on $420.

The point is Musk is looking increasingly like a joke, which is not what you really want in a massive company that is hemorrhaging money and could actually collapse if Model 3 demand doesn't pick up.

<comment><USER5> The backlog of Model 3 reservations is rumored to be over 400,000. Of course I've never seen the split out of reservations for $35k variant versus the currently available $50k+ variety. (Yes it would be possible for Tesla to calculate the demand signal even though people waiting for a $35k variety look like customers that haven't use the configurator) My hypothesis is that his financial model needs more customers of the $50k variety, isn't seeing the demand, and needs to quickly go private before the cash flow becomes problematic again. The evidence I have to support this hypothesis is the lead time for recent dual motor Model 3. It's very short. Once that demand dries up, all that's left is a horde of angry masses waiting for their $35k car that they were expecting to arrive with a $7500 tax credit. Of course my hypothesis is ignoring international sales, which may provide a large enough buffer of premium model demand to keep this ship afloat.

<comment><USER6> The recent push to get Model 3's out with hand labor is going to wreck them in about six months as the recalls and repairs start to roll in.

Tesla had all sorts of tolerance problems early and moving to hand assembly in a tent won't improve it.

<comment><USER7> As someone who doesn't follow Tesla development very closely I am curious is "hand labor" still how Teslas are being produced?

I remember hearing this a while back but thought maybe some of the delays in ramping up production might have been due to switching to an automated/robotic process. Is this not the case?

<comment><USER8> To hit the 5000 in one week (technically took them 8 days), they setup additional assembly lines in tents, and additional hand labor.

Hand labor, working extra shifts, is how they hit their mark.

They continue to use it while they address the automation challenges

<comment><USER7> Oh wow. That doesn't sound sustainable. Is there any concern about quality and consistency of cars produced by "hand labor" in tents? Or is that a non-issue?

<comment><USER6> Definitely. Robots aren't used in factories for speed, primarily. They're used for consistency and quality control.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> It's surreal to watch Musk throw away his reputation and success so quickly and casually. Then again, a lot of things have seemed pretty surreal lately. Welcome to the brave new world of post-reality.

<comment><USER10> He still has his success, unless you actually believe that this lawsuit will bring down the whole company. Also, SpaceX will not be effected.

In terms of his reputation we will see, but most people don't care about obscure stock manipulate rules that he might or might not have violated.

You are way overstating your case.

<comment><USER9> I'm really not. Anyone who's been paying attention lately has seen his behavior become more erratic. It doesn't matter if you're familiar with the vagueries of securities law.

</comment></comment></comment><comment><USER11> Even if the funding is secured, isn't this what "Inside Trading" is about? I really wonder if Elon is aware about what he is exactly doing.

<comment><USER12> Insider trading is trading using non-public information that you had a duty to protect. So, whatever Musk is (allegedly) doing is not insider trading. It could however still be securities fraud.

<comment><USER11> He is using non-public information to liquidate shorters. Isn't that it?

<comment><USER10> No. He is allowed to announce company plans on Twitter. When he said it, it became public and that is legal.

</comment></comment></comment></comment><comment><USER13> Funding secured

</comment><comment><USER14> there is a small chance he's playing a game. by not saying more about the funding , he's fishing for a lawsuit that he expects to win.

unlikely but possible.

<comment><USER15> I know techies like to think that Elon is somehow getting out of this, but legally, if the funding was not secured in full at the time of the tweet, he's fucked under US and EU securities law.

And no one in their right mind tries to fish for a lawsuit. They are expensive, time consuming, and distracting.

<comment><USER16> Why would it have to be secured in full? He wrote "funding secured" that just implies a non-zero level of funding.

<comment><USER15> No, it implies that all the necessary funding was secured because he didn't qualify his statement. Not announcing that they did not have full funding would have been a material omission under securities laws and would have been just as actionable legally speaking.

<comment><USER17> His claim that existing shareholders can keep their stake could mean the projected amount of funding required is very small.

It could mean his personal bank account could cover it.

</comment></comment></comment></comment></comment><comment><USER18> >Plaintiff Kalman Isaacs alleges the announcement was aimed at "completely decimating" short-sellers.

So, what's the point? I think it very well did, but how that's a crime?

It is like music companies suing Napster for them going bankrupt. Or for a person who bet on a losing horse to sue the winner for making him "loose money."

<comment><USER19> The point is actually in the next line :"His lawsuit, and another filed by William Chamberlain, accuse Mr Musk and Tesla of violating federal securities laws and ___artificially_ __inflating Tesla 's share price."

<comment><USER20> Short sellers artificially devalue Tesla's price (and many companies that ate shorted) and thats part of the game. Tesla is actually structured as a financial company, especially with SCTY being combined. The easiest way to destabalize a financial company is destroy counterparty trust. There was a video about the Tesla shorts doing this to other smaller less well known firms. Both media blitzs by Shorts and Musk are questionable but thats how it works.

<comment><USER15> That's not at all how it works.

Musk is the CEO of Tesla and made a public statement. Under US and EU securities laws, if he lied in the tweet, he's liable for the losses of anyone who traded (or didn't trade) based on the tweet, whether or not they were a short seller.

Shorts don't speak for the company. While releasing false information for the purposes of manipulating stock prices is illegal, none of the Tesla shorts have been proven to have done so.</comment></comment></comment></comment>


Here's Every Single Word You're Not Allowed to Text in Pakistan - <AUTHOR> http://www.scribd.com/doc/73348006/Content-Filtering-ENGLISH <comment><USER2> The list appears to have been copied directly from a list of words which the NFL Shop banned from appearing on customized jerseys. So directly, in fact, that the Pakistani list has a gap of three words between "UPTHEBUTT" and "URINATE" (1071 and 1075), right where the NFL list has a few blank lines:

<http://outsports.com/nfl/2005/0301nflshopnaughtywords.htm>

That probably explains most of the odd choices. :)

</comment><comment><USER3> Can someone explain the redundancies to me? If you can't text rot13("shpx") then why do they need to block rot13("shpx") + " you"? Or does that imply that rot13("shpx") + " u" would be accepted (it's not on the list)? Or did someone just not understand how longer strings match faster?

</comment><comment><USER4> A quick skim reveals many words that are plainly innocuous in all but the most devious of contexts.

<comment><USER5> I was performing an assessment of a content filtering appliance once and we obtained the word list of terms that it filtered.

I'll never forget that one of them was "vertical bacon sandwich", which to this day I still think they made up (I've never heard it used in any context ever). We laughed about it for ages.

<comment><USER6> Maybe it was a test case that they used to spot check the filter.

</comment></comment></comment><comment><USER7> You can't text 'creamy' in Pakistan? Is this for real? It seems suspect.

</comment><comment><USER8> Nice to see we have "juggalo" covered. Somewhere, Violent J is smiling.

</comment><comment><USER9> "oui" is on there... wtf?</comment>


Clever screenshot app turns your desktop into Photoshop layers - <AUTHOR> http://layersapp.com/

<comment><USER2> This is actually brilliant. Is wrapping a web rendering engine and exporting the web page as a PSD file the next step?

<comment><USER3> I agree - not a lot of utility in this (for me at least), but I'd pay $100 for something that did this for webpages.

<comment><USER4> is the ScreenGrab! Firefox extension no good?

<comment><USER5> The difference between this and various screen shot addons is that it outputs each piece as a photoshop layer, so they can be easily hidden/moved around.

If you take a screen shot then load it into photoshop and move around a window, you'll get a big white box where the window was, because the screenshot app didn't record any information 'underneath' the window.

</comment></comment></comment></comment><comment><USER6> This is cool and all, but what's the utility? You can already isolate individual windows and arbitrary screen regions with the built-in OS X screenshot grabber.

<comment><USER7> Agreed. While I can see that it's a clever thing and nicely done, I can't think of anyone who routinely needs to screenshot all (or at least multiple) windows at once but separately.

Someone who saves a ton of time using this, please tell us what you're using it for!

<comment><USER8> As someone who does a lot of UI mockups, something like this would be extremely handy. As someone else pointed out, if this saved me an hour of my life, it would pay for itself. If it saved me two hours, it would be saving me money. And an hour of set-up time occupied by taking and assembling selected separate shots of various tool palettes, settings windows, and main editor screens, for instance, would not be out of the question.

It's the "one fell swoop" aspect that is appealing. Just being able to open every possible window in an app and then hit "capture this to Photoshop" when starting on a UI clean-up pass mockup, or for creating a master document of all windows when taking a desktop app from 1st pass programmer art to shipping resources, and sorting them into Photoshop layers and folders, would skip a lot of currently requisite document setup/prep time.

The suggestion to use this to more quickly build manuals and tutorials is also spot on. Grabbing the current state of all windows in an app at "step 3" of a tutorial, and then being able to nudge them around to best facilitate the required tutorial/manual text, without having to manually capture all elements separately, is pretty sweet.

</comment></comment></comment><comment><USER9> very clever.

Now give me an example of this being useful?

<comment><USER10> You're right. A true hacker never writes user documentation for his software, so this is definitely not hacker news. (Ignore this comment if you only ever use MDI applications).

Edit: My bad, MDI interface is as stupid as LCD display.

</comment></comment><comment><USER11> It's pretty cool, but I'm not sold on it being $15 of cool.

<comment><USER12> If it saves someone only an hour of their time, then surely it would be worth the $15 price tag?

<comment><USER11> Hmm, I suppose that's a pretty good point. I would have a hard time justifying the purchase unless I were in a position where I regularly took screenshots of my desktop and needed to move windows around as separate layers on a regular basis.

</comment></comment></comment><comment><USER13> Many comments, not a misleading tile - must be interesting for quite some folks.

</comment><comment><USER14> It's clever but what's really the point?</comment>


Oliver Stone on NSA Spying [video] - <AUTHOR> https://www.youtube.com/watch?v=0U37hl0n9mY

<comment><USER2> I think this is one of the best addresses to this issue that I've seen so far. He gives a concise history lesson and then a point on how to fix the issue. I really hope this message reaches more people. I think that many people worry too much about Snowden and not enough about the core issue.</comment>


To Track Coronavirus, Israel Moves to Tap Secret Trove of Cellphone Data - <AUTHOR> https://www.nytimes.com/2020/03/16/world/middleeast/israel-coronavirus-cellphone-tracking.html <comment><USER2> Yeah, sure, because of the virus.

<comment><USER3> Israel is taking the quarantine seriously, and arrests people for breaking it. I suspect they know if they do "parallel construction" a-la the US it won't stand, so they're shining the light on the methods they'll surely use (whether authorized or not) to figure things out.

And of course, get everyone used to the idea, which will make life significantly easier for them once the Corona situation is long forgotten.

<comment><USER2> Easier for the Israeli government? They have issues with their voters trust as a lot of other countries right now. I doubt that will be very helpful.

</comment></comment></comment><comment><USER4> No, no, believe us, we're tracking and spying on you for your own good. Trust us.

</comment><comment><USER5> I'm in Tel Aviv right now. The Israelis are acting very civilly, helping one another, and are prepared. Don't forget, because of our neighbor problem, everyone has ventilators/gas masks, and shelters with provisions! Nearly everyone has served in the military. It's a very well-prepared nation.</comment>


What's new in Linux 3.2 - <AUTHOR> http://h-online.com/-1400680

<comment><USER2> The algorithm for determining when writeback from memory to persistent storage is interesting:

<https://lwn.net/Articles/456904/>

(Linked from <http://kernelnewbies.org/Linux_3.2>, which has more detail than the HN posted article)

<comment><USER3> I'm curious what is viewed as a backing device. Lets say I have a SAN exporting three volumes via iSCSI to a single server. Does this patch think those volumes share a single BDI, or does it treat them separately?

<comment><USER4> I think the three volumes will be seen as independent BDIs, because that's the simplest implementation (look at the block device the pages are for, don't attempt to count things at multiple levels). Being too granular isn't a problem, because a process will be slowed down if it writes to any of the three iSCSI volumes that are throttled by the network.

</comment></comment></comment><comment><USER5> Making the RC6 engine for Intel graphics the default was reverted at the last minute due to instability, [http://www.phoronix.com/scan.php?page=news_item&px=MTAzN...](http://www.phoronix.com/scan.php?page=news_item&px=MTAzNDg). It can still be enabled manually by adding i915.i916_enable_rc6=1 to the kernel boot parameters, just like 3.1.

Another interesting change concerning Logitech Unifying devices is that multiple devices are now given separate /dev entries, instead of being multiplexed into one device.

</comment><comment><USER6> The EVM part interests me. It provides a way of guaranteeing that a file has not been changed by using a combination of a passphrase and a key stored in the TPM, along with hashes of files stored as xattrs on disk.

More info here: <http://lwn.net/Articles/394170/>

One question I have though is how to guarantee that the kernel hasn't been modified to misread the xattrs or log the passphrase. Anyone know?

<comment><USER7> TCCBOOT? You could verify the source code of the kernel on a thumb drive, then boot the computer with TCCBOOT and compile the kernel from source every time you boot the computer. <http://bellard.org/tcc/tccboot.html>

<comment><USER8> Does your compiler compile itself twice before? 100% security is just never achievable.

<comment><USER7> Ah yes, the old Reflections on Trusting Trust. <http://cm.bell- labs.com/who/ken/trust.html> Fortunately that wasn't nodata's question. Recompiling the kernel from known source should ensure that it hasn't been modified to misread xattrs.

<comment><USER9> I found his moral section on security interesting: "...The acts performed by these kids are vandalism at best and probably trespass and theft at worst. It is only the inadequacy of the criminal code that saves the hackers from very serious prosecution."

and

"I have watched kids testifying before Congress. It is clear that they are completely unaware of the seriousness of their acts. There is obviously a cultural gap. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor's house."

So while interested in trusted code and security, he was also interested in criminal penalties for unauthorized access to computer systems. Of course, it's an unstoppable force and the metaphor with the real world is tenuous --it's just an interesting take.

<comment><USER7> There is absolutely nothing stopping most people from just breaking a window and climbing into their neighbor's houses. But people don't generally do that, because there's a social stigma against it. There's no security around men's and women's bathrooms to make sure only the "right" people go in, but people know they shouldn't do that. There's no physical barrier on (most) roads to prevent a driver from going on the other side of the road, or ignoring lights, but drivers take courses that explain how to drive properly. That's the kind of cultural gap he's talking about. Stealing is easy, but we teach kids from an early age to respect each other's property. We could easily instill the same respect for digital territory, but culture hasn't caught up yet. I think it will soon though.

<comment><USER9> The digital realm does introduce remoteness[1] too though -and there isn't the possibility of immediate repercussions (as one can find in the physical world).

Additionally, the number of people who trespass digital properties are very few, relatively speaking and could be compared to scofflaws, drunk drivers, etc. but, and this is the big but, their impact is asymmetrical. They can have an effect on large numbers of people.

Despite that, I do agree that culture can be changed in a generation.

[1] It's impersonal and removed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> So does that mean there will soon be distro support for the newer netbooks? (full sizish keyboards under an 11 inch monitor with slightly faster AMD CPU is the payoff, but the graphics and wifi have been problematic from what I understand)

It's an important tangent to me: I like the very small laptop form, but the newer models have not been well supported yet.

</comment><comment><USER11> Do they still ship with an out-of-date version of AppArmor? I'm pretty sure the vanilla linux kernel is stuck at version 2.3.1.

It looks like Ubuntu ships with version 2.7 now: <http://wiki.apparmor.net/index.php/AppArmor_versions>

</comment><comment><USER12> I always wanted to be a Linux Kernel Developer. At least, help them with the most tedious task. Where can I start?

<comment><USER13> <http://kernelnewbies.org> is an excellent resource to get you started. They recommend starting here: <http://kernelnewbies.org/KernelJanitors>. I would also recommend subscribing to the KernelNewbies mailing list, to participate and ask questions.

Good luck!

</comment></comment><comment><USER14> Soooo, anyone care to translate this into Bourgeois Geek? o_O</comment>


Ask HN – Preparing for my first internship? - <AUTHOR>

Hi HN,
I'm a CS student who has managed to land his first summer internship at a company that develops networking hardware.
I will not be aware of my team/role until my first day though, and I haven't worked at a corporate environment before. Given that I have about three weeks until it begins, what can I do to prepare for my internship, speaking from a technical perspective? <comment><USER2> Your first day, starts before your first day. If possible, set up pre-meetings with other team members, arrange for email/phone and a place to sit, etc... Also, see if you can participate in a team meetings/conference calls-- as a chance to listen and learn without the pressure to perform and to begin forming alliances.

</comment><comment><USER3> First of all try to get information of that company. As much as you can. Try to get information about the market and competitors.

You also need to refresh your networking knowledge. Osi model, layers, protocols, ...</comment>


The orange/not orange experiment - <AUTHOR>

I didn't think that this new Orange Name feature, which is currently the talk of HN, was a big deal until I read this comment in a completely unrelated thread:
http://news.ycombinator.com/item?id=467657
Without trying to be harsh, and given your 'orange' status I realize I'm walking on thin ice here ;)
[Note how, unprompted, the responder bows and scrapes!]
... and suddenly I realized that I've seen this Frontline documentary before. It's the legendary blue-eyed/brown-eyed experiment:
http://en.wikipedia.org/wiki/Jane_Elliott
"On that day, a Friday, she decided to make the brown-eyed children the superior first, giving them extra privileges like second helpings at lunch, access to the new jungle gym and five minutes extra at recess. She would not allow blue-eyed and brown-eyed children to drink from the same water fountain. She would offer them praise for being hard-working and intelligent. The "blueys" on the other hand, would be disparaged. She even made the blue-eyed children wear crepe paper armbands.
"At first, there was resistance to the idea that blue-eyed children were not the equals of brown-eyed children. To counter this, she used a pseudo-scientific explanation for her actions by stating that the melanin responsible for making brown-eyed children… also was linked to intelligence and ability, therefore the "blueys" lack of pigmentation would result in lack of these qualities. Shortly thereafter, this initial resistance fell away. Those who were deemed "superior" became arrogant, bossy and otherwise unpleasant to their "inferior" classmates. Their grades also improved, doing mathematical and reading tasks that seemed outside their ability before. The "inferior" classmates also transformed – into timid and subservient children, including those who had previously been dominant in the class. These children's academic performance suffered, even with tasks that had been simple before.
"The following Monday, Elliott reversed the exercise, making the blue-eyed children superior. While the blue-eyed children did taunt the brown-eyed in ways similar to what had occurred the previous Friday, Elliott reports it was much less intense. At 2:30 on that Monday, Elliott told the brown-eyed children to take off their armbands and the children cried and hugged each other."
I'm not sure what to conclude about this. Except that I want to issue a desperate plea: Please don't go on to reinvent the Stanford Prison Experiment! <comment><USER2> As the person whose comment you are quoting you completely picked up on what I was trying to signal. Of course I _still_ posted my comment but I felt like talking back to someone 'superior', and of course that is not the intended reason for the change but one of the not-so-nice side effects.

I personally think that the real quality measurement of comments is not up to a mere algorithm and a voting system that is so susceptible to bias.

Just looking at my posting history an hour ago or so to see what if any of my '1' rated comments I should take back considering the effect on the average karma over the last of my 50 posts, and I'd have to conclude that for me that really would reduce the value of HN to < 0.

I'd quit, that simple.

Lots of the meta discussion around this subject has been a pretty good learning experience for me, I consider the time on this 'experiment' well spent in that sense, but I think the outcome to date has only been:

\- more incentive to game the system

\- exploding meta discussions about the subject including one open attempt at revolt

\- something deep inside me that I can not put quite in to words that makes me uncomfortable about distinguishing individuals instead by 'their cover' instead of reading what they have to say.

<comment><USER3> And I'm the orange guy you were replying to. As I replied later in the thread... please ignore my oranginess. I don't like it either. I think it's a mistake. You want good comments to rise to the top, not assume that only people who've made good comments in the past are the people to listen to.

I might have only BS to say on a particular topic, yet get flagged orange because I've said interesting things about other topics.

<comment><USER4> Happily, it appears that with my setup (vista on high contrast black theme and FF3) everybody's just blue. Not that I think I'd actually care if they were different colours; I suspect quite a few of us on here have the personality trait / social dysfunction / whatever of not giving a flying fsck about externally determined rank, and being much more interested in whether a person has earned -our- respect directly.

</comment></comment></comment><comment><USER5> The flaw in your argument here is that in both of your examples there is nothing that the people could do to change their status via behavior.

I think the hope here is that posters who have proven themselves to be valuable to the community will have a tiny bit more perceived authority and thus help preserve the tone of discourse we have all come to enjoy. If anyone feels the desire to see there user name in orange, it seems fairly easy to accomplish that goal whereas in your examples there is no such opportunity.

I think the majority of regulars here aren't going to care too much one way or the other about the color of their name and will continue to post as they always have, and newcomers will have a goal to reach for that will encourage behavior that is in line with what we have had up to this point.

<comment><AUTHOR> I still agree with this, as I was initially inclined to agree with it. It's a few upvotes, people! Surely nobody takes it that seriously!

And yet the sight of someone, out of the blue, acting out some elaborate deference to an orange-named person was quite jarring. Yeah, it was a joke, but the disarming smile is always part of these things, even when it's serious. Which I don't think it is, here, and at any rate it's too early to tell. But I remain... uncomfortable.

It's much like the disturbing feeling I get whenever someone suggests that the solution to the site's woes (whatever they are this week) is to give those of us with really high karma an array of superpowers that we can use to smite evil wherever it occurs. (Fortunately, that really _has_ been treated as a joke, so far. The awesome powers granted to high-karma people -- you can change the color of _your own menu bar_ \-- are cute and completely appropriate.)

It's not a big deal, but if I had the power to turn off my orange name I probably would.

<comment><USER5> I think maybe that deference you noted is one of the intended consequences though. What I have heard overwhelmingly lately is A: HN as it stands now is a great community and B: People wish to preserve the current tone but are worried about the influx of new people who may not 'get' what HN is about.

I see the new 'orange' feature as a way to give a tiny bit more authority to users in good standing with the community, and as such it increases their ability to help maintain the tone as new users join.

<comment><USER6> the influx of new people and the change (loss?) of culture are at such odds with me desire for inclusiveness and internal (personal) regulation, or free will.

<comment><USER5> The point I would ask you to consider then is that a focused topic, even if it is as broad as "Hacker News" will necessarily exclude certain other topics and as a corollary it will exclude or discourage certain types of behaviors.

Because I do have a free will, if I have the desire to behave in a certain way, and it's at odds with the goal of HN, I can choose to use any number of other outlets for my communication, or even create my own avenues.

The counter intuitive truth is that if all of the social news sites where 100% inclusive in terms of content and were 100% homogenized (that is to say, the culture's of those sites fully exhibited all forms of communication/topics) then that would actually inhibit free will because nobody would have any choices in terms of what type of content they wanted to interact with: everyone would be subject to the same exact atmosphere with no viable alternative.

<comment><USER6> i meant inclusive within the bounds of hn's goals. there are still sub communities; eg: dev hackers, startup idea folks. no one is necessarily wrong in their interpretation of hn's community and submission policy. sometimes it is not that the level of comments has gone down but that the amount of comments has gone up. this is bad for the morale of commenter, to say nothing of the time readers waste (since without collapsible threads...). maybe after 20 comments no one should be able to comment.

i'm not advocating homogeneity so much as customized views. as the community grows it becomes harder to be a part of it. there's a social quality i'm trying to explain...and a concern for how exclusion is implemented... but i've spent far too much time on hn today as it is, so i'll let it rest.

<comment><USER5> Ah, yes I do see the distinction you are making after clarifying.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> by and large, this community seems to be fairly resistant to these types of things and to the general woes that plague places like reddit/digg. if an orange-namer starts getting out of line, i'm sure they'll be taken down a peg.

edited to add: about the only problem i forsee with orange names is that they become a self-fulfilling prophecy. "oh this guy is orange, he posts good comments, this is probably a good one too, i'll vote it up", leading to orange namers rarely losing orange-named status unless they really step out of line

<comment><USER8> Just want to note: that was already happening even without the orange. At a certain karmic critical mass, my comments started getting voted up more often. But I'm just as much of an asshole now as I was 9 months ago.

I agree the orange makes it worse; it's a step in the wrong direction. On the other hand, it's not introducing a new problem. And we're all way to obsessed with this silly number.

<comment><USER9> _But I'm just as much of an asshole now as I was 9 months ago._

But you're an asshole we all know. You're _our_ asshole.

</comment></comment></comment><comment><USER10> I'll chip in with a tiny little insight, which I think applies in this whole karmic discussion:

Complex systems encourage simple behaviour. Simple systems encourage complex behaviour.

<comment><USER11> That's a cute aphorism, but I'll mod you up if you can provide interesting examples!

<comment><USER12> Perhaps this is a bit over-the-top, but look at The Internet versus Wordpress versus Tumblr.

Given a blank page, people will create anything. You can take three HTML-only pages at random and you'll come up with 3 very different results.

Given a blogging engine, people will start restricting themselves to the form of their engine. That means you get lots of different posts, but very rarely will you see a blog using the Wordpress engine for something really standout and unique.

Given a system that divides posts into 6 types of content, the vast majority of blogs created will all start looking the same. The average tumblelog is self-referential, generates long winding tags of citations upon reblogs, and content tends to be amateur and haphazard. Very rarely is a tumblelog interesting or a source of good original content, and deviations from the norm are even rarer.

I'm in the middle of writing an essay about how medium affects content - it's taken about 5 months so far, so perhaps it's not quite even "in the middle" yet - and the gist of one of the things that I state is that the more defined your form is, the more rigidly people adhere to it. And form is good for some things. For other things, it's better to keep the form as loose as possible and let people riff on their own.

<comment><USER13> Your observation about 6 types of content is fascinating -- it makes so much sense! The medium is the message, right? So content expands to fill the container it is given.

<comment><USER12> Exactly. As you add more features, you simplify certain things, but you also limit the sorts of things people will come up with.

</comment></comment></comment></comment></comment><comment><USER14> Hey mechanical_fish, drop the meta and come back to talking with me about Drupal:

<http://news.ycombinator.com/item?id=467926>

(Perhaps you've already seen this & chosen not to respond, but I think it's more likely you haven't seen it since my response came ~8 days after your comment. My apologies if the former.)

( _And_ \-- regarding the orange/not orange experiment -- for some reason my erstwhile orange status seems to have goaded me into making lots of little 1 point comments which I know will take me to not orange status if the feature ever comes back -- which is not the response I would have expected in myself. Any experiment that produces a surprising result without harming anyone is an experiment worth conducting.)

</comment><comment><USER15> It will be interesting to see how this changes voting behavior. I know I am already voting up above average gray comments over above average orange comments. It wasn't purposeful. But easily apparent when I looked back at my voting behavior.

I haven't quite decided if I should just completely ignore the orange/gray experiment or if I should see it as an intellectual challenge. In some senses I have much more freedom to post as I please when I'm gray. On the other hand, there is seemingly more influence being orange. And there is something to be said about being gray and still having a highly voted comment.

</comment><comment><USER16> Uhmmmm.... I think the Stanford Prison Experiment is exactly what we want.

We deliberate seek a way to enforce an exclusivity based on a shared hacker "culture" if you will.

<comment><USER17> I think you must be thinking of some other experiment.

<http://en.wikipedia.org/wiki/Stanford_prison_experiment>

<comment><USER16> I also managed to drop the ly of the end of deliberately, that's why my name isn't in orange.

</comment></comment></comment><comment><USER18> The beauty of the Orange name is that it only reflects your last 50 comments

<comment><USER6> good reminder. nonetheless, see noodle's comment for why this fails to console.</comment></comment>


The State of JRuby - <AUTHOR> http://www.infoq.com/articles/state-of-jruby <comment><USER2> So how close are we to using Ruby to build Android apps?

<comment><USER3> Getting there. The Ruboto project seems to be making forward progress. An IRB implementation is at <http://github.com/headius/ruboto-irb>; Check out <http://ruboto.com/> for new information.</comment></comment>


Will the Mac App Store make the sky fall? - <AUTHOR> http://bonobolabs.com/will-the-mac-app-store-make-the-sky-fall/

<comment><USER2> Sky falling? No.

I do expect that there will be some short-term pain. iOS device owners are pretty well conditioned to expect low app prices from the App Store.

Eventually, though, users will adjust. The App Store will have the software they need. Desktop software isn't dominated by impulse buys the way phone apps are.

<comment><USER3> > Desktop software isn't dominated by impulse buys the way phone apps are.

Ah, but perhaps that is true _because_ there has been no desktop App Store. But now there is. Things may very well change.

<comment><USER4> There is a pretty good desktop app store which drives a lot of impulse purchases: Steam. Sure, it's game specific, but they've done a very good job with it.

<comment><USER5> Stuff like these recent holiday daily deal days have spurred plenty of impulse buying for me.

</comment></comment></comment></comment><comment><USER6> This may be a bit out of topic, but I wonder why doesn't Ubuntu (and other Linux distros) improve their App Centre quicker. They have it since so long, but it still looks crappy IMO. From the screenshots I've seen of the Mac App Store, it looks really nice and a giant step in front of Linux.

<comment><USER7> Ubuntu 10.10 is good, suprisingly good compared to its previous versions. Making it boot from any USB memory stick with persistent storage feature was so easy that I suddenly found myself using Ubuntu 10.10 right from the 4GB USB stick on my Laptop.

The overall experience feels different from the others (MAC OS X & Windows) so much so that you almost forget the existence of any App Centre, at least initially.

</comment></comment><comment><USER8> The implicit assumption is that prices of existing applications will be forced lower. Considering that the app store gives new comers a leg up over traditional channels and puts them on equal footing with established products, there is reason to be pessimistic about the prospects of some pre-appstore products. Particularly when existing products may not conform to the technical restrictions required for appstore approval.

<comment><USER9> History with iOS suggests a level playing field will be very short-lived. Once a couple of indie developers hit it big with MacFart desktop apps (don't hate - a friend who bought an iPad for Christmas is proudest of a fart app), the big developers will rush in, crowd the store with marginally higher quality apps compared to the indie developers with fewer features than before, and dominate.

<comment><USER8> I don't believe the iOS model is necessarily the appropriate analog. There were no established iOS applications when the Appstore started. That's not the case with the Mac platform where there are many established products which because of implementation will not be eligible for the MacAppStore due to the implementation restrictions on applications.

In addition, many dual platform [Win/OSX] applications might take a 30% margin hit because of Apple's cut. Such companies face the prospect of either raising their price on all their products and thus loosing any cost advantage; forgoing the appstore altogether and missing a distribution channel; or providing different pricing depending on platform and potentially alienating Mac customers. Companies which have long supported the Mac such as Adobe and Nemetschek AG in particular face these issues.</comment></comment></comment>