glimcat

* Ever notice how people who make claims about why they got banned never provide links to the posts in question? That's because their claims are nearly always false. If users could look at the actual record, their perennial sob story of perfectly reasonable behavior struck down by bullying censors would evaporate. *

When that kind of response comes from the site's moderator, I really don't see the level of toxicity improving any time soon.

It's likely statistically factual, but in context it's just another of the "mean, stupid things" that Paul Graham called you out as being here to address. And you appear to have done nothing to investigate whether the previous user's post was factually correct before slinging personal accusations.

If this gets me hellbanned too, so be it. Conversation and community on this site is a toxic mess that leaves people afraid to post anything. The main good thing is following users like patio11 and tptacek.

http://blog.ycombinator.com/meet-the-people-taking-over-hack...

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.

"Why an “Unlimited” Plan is Toxic for Your SaaS" -- Josh Pigford, Baremetrics

https://baremetrics.io/blog/never-offer-unlimited

"Okay, how do you determine what portion of revenues are profit?" (crickets)

Seriously, I've heard this one waaaay too many times. It's right up there with "you'll work for equity right, and maybe we can throw in a bit of cash if you put in enough hours?"

Not implicitly, although people are free to use that as a negotiation tactic.

If people try to negotiate you down, you negotiate them right back.

You are probably drastically underestimating the marketability of "can write production-ready JavaScript given sufficient time browsing docs & without copying it directly from StackOverflow."

And I only say "probably" because it sounds like you're looking for a local W-2 gig, and there are some places (e.g. rural Idaho) where there's likely to be a shortage of potential employers.

Elsewhere, consider "any company with senior programmers to report to" as a location which is probably hiring, or at least entertaining applicants - regardless of what any public listings may say about what openings exist, or how much experience or what madcap assortment of skills any job postings say that they'd like (yes, like).

People with networks of fake accounts routinely set them up in advance & run simulated activity.

This is normally used for e.g. selling fake likes. It's taken as a given that you will have regular churn as accounts are detected, occasionally high spikes of turnover as fraud detection and safeguards change, that kind of stuff. Often the action of converting network behavior into currency activity is what burns accounts.

Given an alternative way of rapidly converting part of that network into a compelling quantity of USD, and the fact that you're routinely rotating accounts anyway...offering to pay money or money-equivalents for Facebook connections in an automated fashion is pretty much screaming for fraudsters to call in the biggest airstrike they can before you come to your senses.

Let's just say, it's a fairly trivial exercise if you have access to a botnet.

Here's an option for organizing a "bunch of scripts" app that might be less intimidating to maintain.

foo_script.py

    from flask import render_template
    from flask_wtf import Form
    from wtforms import TextField
    from wtforms.validators import DataRequired
    
    class ScriptForm(Form):
        param1 = TextField('Param1', validators=[DataRequired()])
        param2 = TextField('Param2', validators=[DataRequired()])
        param3 = TextField('Param3', validators=[DataRequired()])

    @app.route('/foo-script', methods=('GET', 'POST'))
    def foo_script():
        form = ScriptForm()
        if form.validate_on_submit():
            do_stuff(form.data)
        else:
            return render_template('foo_script.html', form=form)
    
    def do_stuff(data):
        for key in data:
            print '%s: %s' % (key, data[key])

    {% extends "base.html" %}

    {% block content %}
    <h3>Run foo script:</h3>
    <form method="POST" action="{{ url_for('foo_script') }}">
      {{ form.hidden_tag() }}
      {{ form.param1.label }} {{ form.param1 }}
      {{ form.param2.label }} {{ form.param2 }}
      {{ form.param3.label }} {{ form.param3 }}
      <input type="submit" value="Run foo script">
    </form>
    {% endblock %}

    <!DOCTYPE html>
    <html lang="en">
      <head>
        <title>FooCorp Script Service</title>
      </head>
      <body>
        {% block content %}{% endblock %}
      </body>
    </html>

    from flask import Flask
    
    app = Flask(__name__)
    app.config.from_pyfile('config.py')
    
    import foo_script, bar_script, baz_script

    # You need this for CSRF protection & cookie signing
    SECRET_KEY = randomly_generated_secret_key

Also, I'd use gunicorn if you're deploying your own server. It's a bit less intimidating to get set up than uWSGI, and the main tradeoff is that it doesn't support quite as many thousands of users (i.e. not relevant).

That depends on your resources & priorities.

Internal if you have the IT resources & infrastructure for that to be reasonably painless. VPS if you need to access it from multiple public locations and don't want to expose an internal server, or if "internal server" isn't a thing where you work. Heroku if you don't know how to admin Linux or don't want to spend the time worrying about it.

You'd use Flask-WTF for forms.

https://flask-wtf.readthedocs.org/en/latest/

It can also handle file uploads.

https://flask-wtf.readthedocs.org/en/latest/form.html

You'd need to define a model which describes the form fields, handle it in your view, and add it to your page template.

forms.py

    from flask_wtf import Form
    from wtforms import TextField, PasswordField
    from wtforms.validators import DataRequired
    
    class LoginForm(Form):
        email = TextField('Email', validators=[DataRequired()])
        password = PasswordField('Password', validators=[DataRequired()])

    from forms import LoginForm
    
    @app.route('/login', methods=('GET', 'POST'))
    def login():
        form = LoginForm()
        if form.validate_on_submit():
            email = form.data.get('email', None)
            password = form.data.get('password', None)
            do_login_stuff(email, password)
        else:
            return render_template('login_page.html', form=form)

    {% extends "base.html" %}

    {% block content %}
    <h3>Log in:</h3>
    <form method="POST" action="{{ url_for('login') }}">
      {{ form.hidden_tag() }}
      {{ form.email.label }} {{ form.email }}
      {{ form.password.label }} {{ form.password }}
      <input type="submit" value="Log in">
    </form>
    {% endblock %}

Set up a lightweight web interface using Flask. When people log in and submit a job, it gets added to an RQ task queue for asynchronous execution. If they need anything back at the end, job status, results, whatever - that goes in a database. Congratulations, you've just made a simple web app.

If people are actually getting use out of it, go back and pretty it up a bit with a Bootstrap template or whatever, it doesn't take much here to have meaningful effects on user perception. It mostly just has to be nice enough that it looks reasonably professional when people show it off in meetings, which is NOT a cutting-edge design problem.

Add more pages for more scripts as needed, and tag users with permissions so you know which scripts should be exposed to which users.

If merited, go back and add fancy features like generating PDF reports and emailing them to the head of department every week.

I constantly pushed the use of source control when I was a TA for CS juniors & seniors. Of the low-three-digit number of students I interacted with, approximately two of them listened. Many of these had already had internships at e.g. Facebook, Microsoft, Amazon...

Their funding isn't your problem.

Either they can meet your compensation requirements, or they can't and you go elsewhere, or you find a compromise if you both want it to work.

If you're a decent engineer who can get things done and out the door to some reasonable professional standard, there are a LOT of elsewheres.

    "Explicit is better than implicit."

It's fast and readable and there are no "just be aware that" disclaimers to tack on afterwards.

There are two major methods.

Jamming (active):

Broadcast so much noise at the relevant frequencies that it drowns out any other signal the devices might try to interact with. You throw a lot of power into going LALALALALALALALA at the frequency bands you expect the devices you want to jam to be interacting at, then they can't hear each other over you. It's actually not a particularly hard engineering problem until you start worrying about heat and efficiency - you just build a transmitter and broadcast noise at high power.

Blocking (passive):

Use a Faraday cage or sheer mass to prevent signals from being broadcast into or out of an enclosed area. Mass attenuates signals depending on thickness, density, and frequency. A Faraday cage uses a powered metal mesh to maintain constant voltage at a surface, which can kill most transmissions without the need to turn your building into a bunker.

But assuming this is actually allowed by your local laws, you still shouldn't do it. It's hazardous and unethical since it will also disrupt e.g. emergency communications. If you're bothered by impolite cell phone use, you should pursue a social remedy which allows for extreme cases where manners are not the biggest concern, rather than a technical one which is blind to significant edge cases.

For military applications:

You don't have an enclosed area to work with, so you mostly use jamming devices with as much power as you can manage. But this gets used less than you might think from Hollywood, since a major cost of using them is that you're very loudly shouting your general position to anyone who cares about that and access to some basic electronics. Also the really good ones are set up as buildings or vehicles, it's not going to be small if you want power on the order of "shout so loud a civilian radio station can't hear itself think."

Passive compliments:

Anti-radar stealth technology, which is where you try to make yourself as much of a pain in the ass to make out clearly as you can manage. This is far more difficult since you don't have a controlled environment to play with, but there's still a lot you can do with clever shapes and surface design. Also the point is less to make yourself invisible, than it is to reduce the amount of advance warning that an opponent would get, or their ability to respond to changes in your vector.

Chaff countermeasures are easier, you basically launch a bunch of stuff that's highly reflective at the frequencies people are trying to track you with. I think this is mostly an air-to-air thing. It actually works pretty well, at least in terms of "make it less likely that you get shot down." But if the other guy has reasonably modern targeting systems, you can bet he's got chaff too since it amounts to a thing that shoots out tinfoil confetti.

It still often takes me 30+ minutes to set up the environment for a new language, but that's mostly spent doing some reading on how to set it up "right" vs. just executing an apt-get.

Most of which comes down to the fact that official documentation for first-time users is somewhere on the spectrum of nonexistent to crappy. Many languages have pretty good tools for managing virtual environments and dependencies and such these days, but odds are that a new user won't find out about them for quite some time unless they know to go looking.

I do a lot of random reading, often via searching for a conference (SIGCHI, UIST, etc.) rather than a topic. If you can find a full proceedings list with titles to skim over, it can give you an interesting view year-to-year.

But speaking to the problem of intuition and seat-of-pants methodology:

Reading research publications is often a habit of successful professionals, but it really doesn't do much to give you a solid grasp of research methods because they typically say nothing about why they chose the methods they did, or why they didn't choose other methods, or what flaws there may have been in methods you previously made up off the cuff or pulled out of an article somewhere.

The best way, bar none, to deal with that is to be an active part of a community of people who are at or above (mostly above) your experience level. Immersion in a community with superior experience gives you a constant stream of professional growth. For academics and grad students, they have an existing framework that is largely dedicated to providing that, and through many routes in parallel (their department, conferences, weekly seminars with visiting speakers, teaching).

In industry, you're often the one person in the company, or one of 2-3 people, who even has anything to say about the whole "UI is not UX" issue. And reading will help, socializing on social media etc. will help, but you also have to make an effort to talk shop with other professionals on a regular basis, who are at or preferably above your skill level.

Meetups can help, to the extent that people who know more than you are there, and that you actually talk shop (pound for pound, you may find more misinformation & marketing). If you're near a university with a decent program in this area, you can also poach their meetups. Go to seminars or whatever, it's not like they'll usually check ID, just don't be disruptive and you're fine. Some are explicitly open access, which you should be taking advantage of whenever possible.

Basically, "don't be the smartest person in the room."

If you're not growing, either find or make a new room that has people above your skill level in it. Then interact with them, about professional issues, and be prepared to put your ego aside.

This is a reasonably well known problem in video processing, often referred to as "background extraction." It mostly amounts to running local outlier rejection on the video frames then generating a composite image. There are better and worse algorithms for this, but it's just noise rejection. Start with a median filter, tweak window size and number of frames, exploit color if desired.

Key trick is LOCAL outlier rejection. You don't take the median of the global dataset, you take the median of a subset of frames. Then you do it to a subset of results, and so forth until you get a pretty image. Then you can highlight problem areas and go back and try to sample them from different data, depending on how much you care about that. An incidental benefit of this is that it lets you dramatically speed up the job by throwing CPU cores at it, if that's something you care about.

(Lots of relevant academic papers for after that.)

The problem encountered in the article is that 2100 frames gives 22.4 MB per frame, which napkins out to 5.8 gigapixels uncompressed. For reference, at 30 FPS that would result in 70 seconds of continuous video. Using high-res stills is going to balloon your storage cost & processing time, which has nothing to do with underlying problem.

A good workaround if you want a high-resolution result would be to do processing at a reduced resolution, then upscale from there. E.g. if you drop resolution by 1/4 for processing, you could take the output and for each pixel find the best matches in the source data and sample a larger window from those to get a full-resolution result.

Or you could use one of those nifty video super-resolution algorithms that have been popular in recent computer vision papers. Depending on what you chose to do when you captured the data, and what you feel like implementing.

Times Square is still problematic, mainly because it has persistent crowds during many times of the day. People move out of the way, crowds don't unless there are gaps (which may be inserted due to e.g. stop lights, transit arrival times). Best advice there is to catch it when the traffic is less dense, or when it's disrupted (movie filming, accident, random variation).