chton

That's why it's important that it's a one-time donation, not a recurring additional paycheck. If you give 'the poor' an additional paycheck, yes, it will have an impact on the willingness to work and save. If you give them a one-time donation, on the other hand, they can use it to improve their lives in the longer term, without reducing work. That's what the data (as quoted in the article) shows.

I believe the reasoning for why that should be goes back to the cycle of poverty (http://en.wikipedia.org/wiki/Cycle_of_poverty). It's harder to make more money if you don't already have more money. By giving a one-time lump sum, you give people the opportunity to dig themselves out of that hole. Eating better, dressing better, buying things that last longer, these all have big impacts on how much one can save and earn. Even getting some basic education helps enormous amounts. In the end, it might even lead to people being more willing to work harder and actively save more money.

Today, not very many places. I can imagine a scenario where you want a large group of these to crawl through rubble to find people stuck under it. Most research like this comes with the hope of miniaturizing it enough for medical applications. Imagine this thing, but the size a grain of sand: entering your bloodstream, adapting to whatever task that needs to be done, and when it's finished moving to the stomach to get dissolved. In those applications, using external power makes complete sense, since it's a medical setting anyway, and it provides a great way to keep very fine control.

Just a note on 2.: If your onetime price is equal to just 6 month subscription time, you're going to lose money. Either you're lowballing your onetime payment, or making a subscription too costly. Consider a case where you offer both at the same time: Unless the costs associated with self-hosting are incredibly high, very few people would choose the SaaS option if they can save 6 months of budget on the first year. In this case, I would increase your price to at least a year of SaaS subscription.

As to your original question: Unless your software is special in some way that you don't want anyone to find out about, you can offer both SaaS and self-hosting at the same time. My advice would be to do that, but use a yearly-license model for the self-hosting. Calculate the costs a self-hosted version would cost in total to a client (license, hardware, maintenance etc.), and make the SaaS version slightly cheaper than that.

In addition to the great ones already listed on the link and in the comments here, I'd like to list 2 of my favorites:

* Simple.Data: https://github.com/markrendle/Simple.Data , the smallest and simplest ORM you'll ever use.

* Hyperletter: https://github.com/Jiddler/Hyperletter , a very easy way to do inter-process communication. Great for writing distributed software over http, but can be just as useful locally.

My pleasure. One thing I forgot to mention is that I try to never use negatives in boolean names, both for methods and variables. The moment you start with "IsNotXXX" or "HasNoXXX", you're creating a new way to potentially confuse future readers. If you can, always try to find a positive way of expressing the same, it'll usually be less ambiguous. If it really is necessary to express a negative, perhaps because the reverse is too broad or hard to formulate, it's usually better to invert the meaning of the boolean entirely. So instead of

    if(IsNotFoo) {}

you can do

   if(!IsFoo) {}

It's a simple thing, but it can save you valuable time and brainspace at some point in the future.

The best practices are going to be somewhat language-dependent. In general, the least confusing style is the one that is already used widely in the application you're writing.

If it's up to me to decide a naming system (I mostly do C# professionally), my boolean-returning methods will be in the form of a tiny question that has a yes or no answer:

    IsEntityPersisted()
    WasActionPerformed()
    IsFooOfTypeBar()

etc.

For variables, local values and method parameters, the names will be similar, but in the form of a true or false statement. The equivalent would then be:

    entityIsPersisted
    actionWasPerformed
    fooIsOfTypeBar

The important thing in both cases is to name the boolean for what it means, why you'd set it to true or false, not for how you intend to use it. Compare:

    if(logicFlag)
    { 
     //do something
    }

vs

    if(actionWasPerformed) 
    { 
     //do something
    }

Clarity in a naming schemes is all about making it clear what something means in the context. I know that sounds like a tautology, but there is a difference between "what something means" and "what something does in the application". If you manage to make the meaning clear, the reasons for what it does will become clearer too. The reverse is rarely the case.

That's because you can conceptualize what happens through your experience and knowledge. For a newbie, a slight benchmark increase doesn't mean anything because they can't tell what the impact of it is, why it is important.

Closing the feedback loop between typing and seeing a cool result is one of the best ways to get people excited about coding. If 3D or AR helps with that, it's definitely a good thing :)

I can't speak for the Surface 3, but I have owned a Surface Pro 3 for a good while now. I _never_ use the trackpad. Browsing, office, even doing software development can all easily be done using finger and pen (for when you need finer control). I've gone so far as to check if there is a Type Cover for it that doesn't have the trackpad, but uses the space for something else.

I know it's the popular thing to say that Windows 8 isn't fit for touch devices, but it's outdated and usually only reiterated by people who don't have any proper experience doing it.

That is the case. All the way at the bottom of that page: [6] Surface Pen sold separately.

Mechanical keyboards are like the whiskeys of the keyboard world. They're not for everybody, and can be an acquired taste, but there's a huge amount of people who swear by them. They're also a premium product, so there is a bigger barrier to entry than the normal products.

To me, a mechanical keyboard has been brilliant. I bought a Razer Blackwidow a few years ago, and haven't looked back. It's much easier to type quickly on than a non-mechanical, because every sensation of it is so defined and fast. As a programmer, that means the connection between my brain and my computer feels more natural.

However, I know programmers that can't stand the increased sound and don't need or want the speed.

If you can afford to buy a keyboard on a whim, I would say "try it and see". The only way to know if it is for you is by trying one for a while and weighing the benefits against the negatives. Even if you don't particularly like it over a regular rubber dome or ergonomic keyboard, at least you'll have a premium keyboard that will last you a long time and will be better constructed than most.

I've been using shumway for a while now. Thank you so much for making my web browsing experience lighter and faster. It's a huge improvement.

You're now also a laughing stock of the entire VC industry, you have an insane amount of stock worth absolutely nothing, and you're under investigation for trying to defraud corporate taxes.

Oh, and you've also proven that you don't know the difference between valuation and money. Or why valuations from other VCs are what they are.

One of the most interesting exceptions I've seen on this convention was the 2011 movie Limitless(http://www.imdb.com/title/tt1219289/). They still used the orange-blue complement, but switched saturation between them, sometimes every scene. It was used as an indicator of how the protagonist views the world: bright and with an orange saturation for when he is on NZT, dull and blue when he isn't. I thought it was a great way of deconstructing this particular trope.

I definitely do too, they are capable of too much for them not to have it. But it should be granted to the entire species, not just to any single orangutan.

There is a big difference between having your rights violated and not having rights at all. The fact that we know the torture practices are wrong is because they violate our rights. We treat apes badly because they have no rights to which to compare the treatment.

I don't think that's what they mean. My interpretation of that statement would be that rights are conferred to species as a whole, not individuals, and it matters whether the species as a whole can bear legal responsibility. Just as you can't take rights away from individual members of a species that can do that, you can't give rights to individuals of a species that can't. How you define what species can and what can't is of course the clincher in that case.

In a way, it's a pretty decent way to look at it. It means all that is required for an entire species to be given personal rights is to prove that they can fulfill the obligations that come with them. It decouples the rights from the good or bad inviduals, and reduces it to "what is this genetic grouping capable of".

It's very comforting to see commit messages like https://github.com/mit-athena/discuss/commit/6359a0ae817ddda... and https://github.com/mit-athena/discuss/commit/911e5877bf2e9cc..., even from as far back as '86. Developers have occasionally felt stupid and unmotivated for a loooong time :)

That's entirely true for the current generations of 3D printer, but how do you know they won't improve in the future? If printed tools ever become good enough or almost good enough to compete with the quality that a traditional manufacturer can provide, they definitely have a chance of becoming more economical. Cutting out transport, work, and other such costs can make up for it.

I don't know when that tipping point will happen, but it would surprise me if it's decades for common tools. Printers have made great strides in just the last few years, and if the current pace of development keeps up, they could reach parity in the very near future.

It could also be far more revolutionary. They make it sound like they invented a small-scale holodeck. If that is the case, no matter how it works, or how limited it is, the potential is huge. Realistic holograms would be a major step forwards in connecting computers to humans.

I'm not an iOS developer, so take what I say with a grain of salt:

- The first call mentioned seems to request a URL for iCloud. According to official guidance (https://developer.apple.com/library/mac/documentation/Genera...), you shouldn't call it from a main thread. Is it possible that the poster is doing that? The trace he gave indicates it went wrong during a wait, so that would be the first avenue for searching.

TestFlight may be testing an edge case, but experience learns that if their configuration allows them to do something that crashes your app, you'll have problems like that in the wild too.

- In the second problem, the submission to the appstore, the note from the reviewer clearly indicated that it did launch, but it did not run at the correct resolution. It's supposed to maintain the resolution it would have on an iPhone, not scale up or down by itself. Forgive my bluntness, but this problem seems to be one of language barrier, not of Apple's testing systems.

The post writer comparing his problems to Panic Inc.'s seems a bit much. Panic had a genuine problems with the rules, not a technical one. For them, the process didn't go wrong, the rules it followed simply weren't up to snuff.

The practicality is a very personal thing. For me, it's helped me see that a wider variety of things match the definition. Realizing an Actor model, communicating processes, microservices or nodes in a storage model can all be seen as objects, and applying some object oriented modelling techniques to them, has been a very powerful tool for understanding them and building them. This value is entirely personal to me, though.

No apologies necessary, it was absolutely fair to call me out on a bias on my end. You too thanks for the discussion :)

It's definitely possible that there is no one good definition, but it's a good discussion to have. I applaud that you treat this with your class.

The usefulness is debatable. To me, it's been useful because it helped me see that, for example, a process can also be an object, and you can apply object oriented rules to interacting processes. The Actor model is an extension of that. Modelling a set of Microservices as an object model has also proven valuable.

How you communicate it to students is a not an easy matter. I'm opposed to giving definitions as an absolute truth if they aren't, even if you're doing to prove a point. If you want to teach with different definitions, that is of course perfectly fine, but at least a mention of the debate could solve some later problems. People tend to adhere to the 'laws' they learn for a long time, and if you teach them a definition that is incorrect in some cases, they'll have trouble with those cases.

How you refer to state or behaviour is not strictly relevant to the definition of an object, because it depends on how you implement it. It might fit in the language it was used in, but it doesn't in others. Behaviour might be reactive on state changes, it might be perpetual in a nameless loop, it doesn't matter. In the same vein, referring to state as values and behaviour as functions is too narrow. The lifecycle of the object is part of its state too, an object's construction and destruction is part of its behaviour. That may sound like hair-splitting, but it can seriously trip you up and give you a wrong idea of what an object is in non-conventional settings. An object is more than a map of 'name' to 'value or function'.

It's possible that my dismissal of many definitions is partly because they're not my preferred one. I'm human, so it's most likely the case. I like to think my preferred one at least came about through some investigation, and it's the only one that I've seen fit a wide enough variety of cases. For me, at least part of the validation comes from the fact that I was frustrated at the definitions people gave me long before I found one I liked. Too many conversations with college teachers, mentors and colleagues that went

  "So how would you define/describe an object?" 
  -"..."
  "OK, but what about [language/edge case/model]?"
  -"Oh yeah..."

I'll gladly have this conversation again, and again, and again, and I hope somebody can poke holes in the definition I prefer, and put me on the other side of it.