glimcat

At a minimum, one could start an American company, which could at some point start a Japanese office (with all the accordant overhead in terms of paperwork and politicking, including the usual risk of immigration taking a dim view or otherwise filing your paperwork in the "do not pass go" column).

How closely that approximates the desired scenario with regards to e.g. hiring and social signalling is another question. It would presumably be bounded by the status of e.g. Microsoft Japan, which is in turn bounded by Sony. Which is to say, not as good, but possibly good enough for most intents which don't involve hiring new grads shoulder-to-shoulder with Sony.

It's easyish to derive to good accuracy from the accelerometer signal alone (which I believe is always available).

Great example of issues I would probably never catch if I tried to implement all of this in-house. It just wouldn't get that level of attention once it was already working.

"Oh, that's easy, I could implement all that in a weekend" - One, no. And two, no. Problems are always deeper than they seem, and it's usually the extra 90% that determines how well it works.

Archive it and move on with my life.

The work is generally entangled per the terms of your contract. If you want to do anything particular with it, the contract needs to cover that.

Specific things you may be thinking of:

* Showing off "portfolio samples" based on incomplete work - this is apt to annoy clients if you're not careful with it, and any given portfolio sample is unlikely to make or break your ability to land clients. If you think it might, you need to take a hard look at your sales process.

* Code reuse - this should be something your contract already covers for all projects. This code is mine, I am licensing this particular configuration of it for you to use based on specific terms, and assuming that you complete your end of the contract (i.e. pay me).

Well here's the essential bits in Python. I leave turning this into an actual CLI as an exercise for the interested reader.

    from requests_oauthlib import OAuth1Session
    import json


    keys = json.loads(open(keyfile).read())
    #  {"TWITTER_CONSUMER_KEY": "blah_blah_blah",
    #   "TWITTER_CONSUMER_SECRET": "blah_blah_blah",
    #   "TWITTER_ACCESS_TOKEN": "blah_blah_blah",
    #   "TWITTER_ACCESS_TOKEN_SECRET": "blah_blah_blah",}


    def twitter():
        return OAuth1Session(keys['TWITTER_CONSUMER_KEY'],
                             client_secret=keys['TWITTER_CONSUMER_SECRET'],
                             resource_owner_key=keys['TWITTER_ACCESS_TOKEN'],
                             resource_owner_secret=keys['TWITTER_ACCESS_TOKEN_SECRET'])


    def tweet(status, reply_to=None):
        endpoint = 'https://api.twitter.com/1.1/statuses/update.json'
        data = {'status': status}
        r = twitter().post(endpoint, data=data)
        return r.status_code


    def tweet_with_image(status, imgfile, reply_to=None):
        endpoint = 'https://api.twitter.com/1.1/statuses/update_with_media.json'
        data = {'status': status}
        if reply_to is not None:
            data.update({'in_reply_to_status_id': reply_to})
        r = twitter().post(endpoint, data=data, files={'media[]': open(imgfile, 'rb').read()})
        return r.status_code

Optimizely takes minutes to sign up for - and they're always looking to make that easier, and to make more people aware of the value they provide. In contrast, the expertise to conduct tests that alter revenue outlook takes somewhat longer to develop.

Sure, people could go out and spend the time to learn just about anything. In practice, they won't, because that's competing with all the other anythings they could be doing.

Sell the thing that actually has significant barrier to entry.

You take care of the easy thing too, because making the client spend meaningful attention on something that would take you five minutes is just silly, and you're there so they don't have to worry about that stuff. But sell the hard thing.

The fundamental error with trying to fix such marketplaces via another marketplace is that contractors are typically far better off relying on repeat business and some elementary lead prospecting, while project owners are better off relying on networking and repeat business.

Your target market is thus (more or less) restricted to people who don't yet meet that level of experience and professionalism. You get the contractors that have no existing clients and no clue how to approach companies, and you get the project owners who are out to get bargain-basement labor and firmly believe they'll be the one poster who gets lucky and finds a contractor who works on the internet yet is too inexperienced to realize what that means for their billable rates.

This is still a potential market, but you've lost the more desirable end of the pool before you even leave the gate. And even if that is the end of the pool you want to provide value to - you can provide far more value by helping them move upstream, rather than trying to stamp out another marketplace which is a bad solution from its conception.

Exactly. Server-side vs. client-side rendering of HTML is just another optimization choice.

Is it more important to shorten the time to display the current request, or to shorten the time for new pages to be rendered? Single-page apps marginally increase the current request's time-to-render in exchange for improving navigation between pages. For some purposes that provides a significant benefit, other times it doesn't.

I do programming like I do algebra. It's a tool I use to solve problems.

Mind you, it's a tool I'm very good with, and that I get intrinsic enjoyment from when using it. But I don't do it 24/7, and I also get intrinsic enjoyment from woodworking, soldering, cooking...

Some people are invested in getting you to believe a narrative where coders code, all the time, 80 hours a week even if you don't pay them, like they're one-dimensional widgets instead of people. If anyone tries to feed you that line, I'd take a good hard think about why.

I routinely do machine learning and computer vision, and have used a number of languages for them.

The main issue, irrespective of language, is that the implementation of your final model is often a distinct step from the last output of your experimental tools. If you just take what it gives you and try to deploy that, it will often provide extremely suboptimal performance.

The methods for implementing your final model could involve raw Python, NumPy, the Python wrapper for an external library, writing and consuming custom C libs...it depends on the complexity of the hyperplanes.

But e.g. scikit-learn already wraps libsvm and liblinear. If your SVM (etc.) is slow, it's very unlikely to be because you used Python.

If you're e.g. trying to do Facebook-level heavy lifting, your experiences may vary. But again, that would be a challenge for any tools. The solution is to use sampling, parallelism, etc. - and to implement and optimize your final model as a separate step from designing it.

The only reason Python should ever be problematically slow is if you're writing bad Python. (Well, almost ever.)

What you have to understand is that pythonic Python is largely a matter of invoking C libraries, and that Python only really runs at "interpreted" speed the first time you invoke the code.

It's no more slow than a shell script which serves to invoke grep and sed would be, because you're relying on the underlying optimized tools to execute the bits that would actually benefit from optimization. The microseconds it takes to switch from one to the other are almost never going to be a meaningful slice of the total execution time.

Instead of picking over the mostly insignificant delays that are left, Python has said "hey, let's optimize for readability & developer sanity instead — things that actually affect project outcomes." And then you go knock off 10 different issues you wouldn't have had time for, and you don't stab yourself in the eye with a fork while trying to make sense of the old code.

Python is the best at quite a few things these days, particularly if you need to accommodate projects (or developers) that require top-caliber tools for getting work done in several different problem areas.

The whole 2 vs. 3 is, if anything, an embarrassing interlude in getting to the fact that it's currently both amazing for beginners and one of the most versatile professional languages. Where it's not the best, it's often fighting "mainly good for this one problem area" tools and languages to a draw...while still being great for dozens of other problem areas.

Cracks about "really easy to use orbital death cannons being handed out to anyone who asks" aside - your best comparison is probably a trench knife. Simple, elegant, gets the job done whatever that job happens to be.