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) {}

   if(!IsFoo) {}

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()

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

    if(logicFlag)
    { 
     //do something
    }

    if(actionWasPerformed) 
    { 
     //do something
    }

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 agree, my gripes are not with the entire document, or even with the chapter in question. I also don't have a problem with starting from a statement that may be wrong in an informative way, it's a valid approach to learn a subject.

My problem is that it's not presented as a starting point or even implied that the definition might be wrong. It categorically states "The simplest notion of an object—pretty much the only thing everyone who talks about objects agrees about— is". If it had said "One notion of an object -one that many people who talk about objects agree on- is", all would be dandy. When you're stating things as fact in a document dedicated to learning, they should be solid.

My other gripe is that I've heard too many vague, biased or incomplete answers to the question "what is an object". These are structures people use every second of every day, but they've never learned a proper definition for it?

Alan Kay disagrees that objects exist to 'encapsulate state'. I agree with him. They also encapulsate behaviour. While it's difficult to get a precise overview of Kay's definition (he never gave them explicitly), this page does a good job of collecting the various bits: http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

Notable for the "behaviour and state":

   3. Objects have their own memory (in terms of objects).
   4. Every object is an instance of a class (which must be an object).
   5. The class holds the shared behavior for its instances (in the form of objects in a program list)

And more importantly, as a first sentence to explain what an object is, it's misleading and will raise a lot more questions later.

It's surprising to me how few developers, even hardcore OO developers, are able to just give this minimal definition. It's the core of the entire paradigm, that an object is state and behaviour on that state, and yet everybody always gives some convoluted, hardly understandable-to-a-beginner definition. If you're going to be teaching people, "behaviour and state" should be your starting point, not "a value that maps names to stuff". Seeing how the latter maps to an OO language is not trivial, something it should absolutely be.

It crystallizes my ideas. In more than one way. It still staggers me that I can think up complicated structures that do entirely new things, even impossible things, and put them into practice using only my fingers and mind. I love architecture more than code, but code is the way to bring the architecture to life.

It also works the other way around. Code helps me think. It's rigid and exact, and doesn't allow for vagueness in ideas. It means that, when I'm coding, I'm required to think things through. It forces me to bring blurry notions into sharp focus.

And lastly, I believe it makes me a better person. Programming is a refined balancing act between abstracting and precision, between simplicity and complexity. Doing that balancing act makes me more capable of handling other situations. It trains your mind to understand complexity and reduce it, just as it trains it to see the problems with simplicity that make it more complex.

Oh, and it's also a great way to pay the bills. But I would still be coding if it didn't, I'd probably still be coding if I had to actually pay money to do so.

hoo boy, this article sounds like it was written by somebody who only had a first-year course in OOP. I hope it's mostly tongue-in-cheek, but in case it's not, let's quickly go through it:

1. Paradigm: The paradigm of Object Oriented Programming follows directly from its definition of an object: a structure that contains both data and behaviour. Objects are your first class citizens. "Everything is an object" is, for most, a goal. Everything else, all the variations on how to formulate it or how the language implements it, are interpretations of how to do that.

2. Object-Oriented Programming Languages: I agree, everybody has their axe to grind with another language. This is no different from other programmers. On the flip side, for most this axe-grinding is pretty light-hearted. In a world as big as the OOP one, rivalries are everywhere.

3. Classes: "There is a complete disconnect in OOP between the source code and the runtime entities". Because the runtime entities contain data. Classes determine the behaviour on that data. It's a direct consequence of nr. 1. OO Code shows us the behaviour of an object, interacting with the behaviour of other objects. Everybody is free to dislike it, but calling it 'nonsensical' is ridiculous. As an aside: there are IDEs that show objects. BlueJ (https://en.wikipedia.org/wiki/BlueJ) comes to mind. They tend to be educational tools, because seeing and inspecting actual objects during development means you still need to work on how you mentally model the code.

4. Methods: Methods should be a sensible length. Make them as short and as sweet as is possible, but no shorter. If you need to go bouncing around huge amounts of tiny methods to figure out what is going on, you have a code smell. If you have to search through a 1000-line monster of a method to figure out what is going on, you have a code smell too. The goal is to find a sweet spot, not to apply some rules to their extreme.

5. Types: I'll be short on this one: the point of types is to make sure you don't accidentally do something stupid. In the process, they make other things harder, but also more predictable. If you don't like that, no problem, there are OO languages that are dynamically typed, or ducktyped, or any other variation on the theme.

6. Change: I don't quite know what the author means with change here. He seems to mix up change of the program (maintenance, extension, etc.), with change in the program's environment.

7. Design Patterns: A standard way to solve a standard problem. Refusing to use them or not knowing them will lead to either bugs or reinventing them. If they 'make your design more complicated', you're using them wrong.

8. Methodologies: Are a general problem in all programming, and always have been.

9. UML: I'm a professional developer. I almost exclusively do OOP. I haven't touched UML in years. I haven't seen UML in years, not from other developers, not from architects, not generated by the code. The code is the code, the modelling language is a way to communicate about the structure of the code. Reversing that relationship just means you're hiding code behind a graphical representation. See also: BlueJ.

10. The Next New Thing: Happens everywhere.

The conclusion sounds like a complete inversion of the original premise of the article. I agree we have a long way to go in OOP, and I agree we are still in the early days of OOP. But hating OOP is as shortsighted as hating FP, or procedural programming, or any other paradigm.

It does vary from person to person, and from job to job. For me, it's less than 25 days, on average. Others might need much more. I won't judge anyone for taking more vacation time, and I'll respect it as best I can. I just like having the option of not taking time if I don't want it :)

Oh absolutely, I consider any time you take to stop yourself from needing more time off to be 'needed'. The goal is to stop long-term accumulation of stress, not to remedy it when it gets too bad.