1. Ask nicely.
2. Ask via lawyer.
3. Ask via judge.
It sounds like you've already tried the first two options.
1,720 karma · joined July 15, 2011
2. Ask via lawyer.
3. Ask via judge.
It sounds like you've already tried the first two options.
For something the size of a plausible ship, the surface area is astronomically smaller, while the temperature of most of its surface would likely be kept at or lower than the range which is compatible with macro-scale organisms and biochemical processes. A ship would also be trying to manage its heat, probably using an insulating exterior.
Meanwhile it would be pointing its thruster - the only part meaningfully above 300K - away from you for at least half the trip if directly oncoming, with angular efficiency coefficients if heading somewhere else. Recall that the ship itself is insulated & temperature-regulated, and therefore shields the emissions of the thruster. The thruster would also likely be focused as much as possible, so we could expect thermal radiation at steeper angles to drop off sharply.
Even something like a nuclear pulse rocket would be hard to spot until it was within a very small neighborhood, and then it would be up to whether you're actually observing that part of the sky during the time when it might be visible.
Ships are very hard to detect until they're almost on top of you.
But they tend to have low efficiency, thermally-dependent efficiency, and the need for a temperature differential. They operate in response to a temperature gradient, not just heat.
Using Wikipedia for a quick-and-dirty figure, you can expect efficiencies to peak around 5-8%. And you can't just stack infinite thermocouples until system efficiency reaches 99.99% because of the thermal gradient issue.
If there's a lot of it and you're not making it go elsewhere, assume that the system and it its environs are going to get a bit toasty.
Sometimes you also get things like radiation and vibration. These mostly show up in meaningful quantities in predictable places - nuclear systems, mechanical systems, high-power A/C or RF systems, high-power transducers.
You'll usually do okay if you guess that the system uses energy at around ~60% efficiency, which is enough to give you some idea of the heat to expect if you know the input power.
Or more generally, assume all input power goes to heat and plan to handle operation at that limit - while being aware that your expectations of power consumed by the system may well be low.
If it's out of pocket - it really depends on what else you'd need the money for. They do post videos.
That's not the issue. The problem is that it gives the government the ability to arbitrarily circumvent the usual ethical safeguards and legal protections which come into play when bringing a criminal allegation.
Since the practice obfuscates at least part of the evidentiary chain, there's no way for a private citizen's legal defense to audit it for compliance with ethical and legal standards.
Also, given sufficient surveillance data and complexity of law, you can probably come up with some criminal charge against any arbitrary person under surveillance at any time when it would be useful to do so.
> intelligence agencies to make any criminal allegations
"Here's some data, that guy is inconvenient to us, please accuse them of this list of legal violations which we have just given you supporting evidence for."
If you know a reason why it wouldn't work like that - one which can still be enforced in open court, not a secret court known for rubber-stamping virtually anything brought before it by the government - I would love to hear it.
Math is kind of a broad area. Some people coming from it will have a very easy time adapting to software or finance, others will have to start more or less from scratch. There's also the question of whether you'll like it. Good signs are if you're more towards the applied / problem solving side, and if you have fond memories of playing in Mathematica.
Since the problem is fit and lifestyle more than other issues, you might consider going for internships first. This would give you a way to get your feet wet and test for fit before over-investing too much in one path, and it could also give you an easier way to transition into the industry.
And yeah, LOTS of people do get into those fields from math, random sciences, engineering..."your major is not your career."
Note on internships:
At least in the US, internships do have to be paid if you're producing actual work product - despite what a lot of companies will try to pull. "Companies who are unaware of basic employment law or who think it's fun to flout labor laws" is a good filter for companies that aren't worth your time.
When Tor is actually appropriate, the drop-and-go version is the Tor Browser Bundle, which uses a customized Firefox distribution.
https://www.torproject.org/projects/torbrowser.html.en
Note that all this does is proxy your requests, it won't prevent you from deanonymizing yourself through characteristic requests, traffic patterns, or whatever. That's often where people screw up, since it involves a running battle where losing a few bits of entropy here and there can and will expose you.
But to explain it:
A group of people don't want others to be able to snoop on what websites they want to view. So they agree to lump all their requests together, and then they don't keep any records about who ordered what once it has been delivered.
If someone's snooping, all they can tell is that someone in the group requested it - they can't point a finger at any specific person.
If you don't market a feature, or if you're marketing it beside 100 other features, it doesn't exist.
Even with the resource constraints of the average mobile device, you can often have the operation complete in less time than it would take to transfer the image, particularly under field / non-LAN network conditions.
One simple way around this would be to specialize in more intensive operations, particularly with parallel algorithms that can be done quickly by throwing 50 workers at it. Or alternatively, you could look for situations where the user needs to process a large batch of images asynchronously (then throw 50 workers at it).
There is a lot of room on the market for image processing tools - software, libraries, APIs, whatever. But basic operations which are already well-supported by many drop-in FOSS libaries are usually going to be hard to bring to market.
Add something extra which solves problems unique to the customer's problem domain or workflow. Then you become "the only" instead of "yet another."
The standard is probably using ImageMagick & an appropriate wrapper. Why is using your solution better?
Take into account that you're at least doubling the transfer latency involved, which will frequently dominate the time required to complete an image operation.
end_user->your_user->end_user
end_user->your_user->you->your_user->end_userI'm curious what motivated the switch-off - compared to the LTV-weighted number of users attracted or retained, was it consuming too much support time, compute resources, dev maintenance hours, team mindshare?
It seems like a case of "this isn't working for us so we need to stop having it on our list of things to think about," but maybe there were other inciting factors for the EOL decision?
The only use case you really market is as an API. At least that I've been exposed to, across several channels, after actively investigating which ESP I wanted to use, after actively paying attention to marketing from you and your main competitors for several years. So...yeah.
I can find documentation easily enough now that I know to check the docs for it, but maybe it's more an issue with publicizing this aspect of the service?
If you're more concerned with building a business, the optimization criteria are different. Your priority should be building the business - or at least building enough of the business that you can start acquiring customers and pitching to investors. That gets you runway, market leverage, knowledge of what you should be building to acquire and keep customers.
You can worry about implementation details like tech stack after the business exists. Worrying about it before you know the business is even valid is premature optimization. You are orders of magnitude more likely to fail because you don't start than because you chose the "wrong" tools.
For simple apps, it doesn't matter much. Do what gets you in front of users soonest.
For more complex apps with a lot of client-side state, you may quickly find yourself outside of jQuery's intended use case. Note that simple apps often become much more complex under ongoing development.
What creates problems is trying to pile on a lot of questionable commits without enough structure or organization, and trying to shoehorn it into use cases which it's really not appropriate for. In practice, these situations occur much more often than people anticipate.
Also, it will probably boost their engineering productivity by 10%.
Any of the above is probably "dogfooding" for small companies where people wear many hats while having lowish internal firewalling and power disparity. It's often much less useful at a BigCo where the product team may never see the internal users without scheduling a meeting in advance, and where fixed development schedules and internal politics are creating design lock-in.
Also keep in mind that, for every story about dogfooding improving product quality, there are others about dogfooding creating a runaway blind spot because the company confused the needs of internal users with the needs of customers. Internal use can be a useful resource, but it can't replace customer research.
Look for high frequency access with low variability in the delay between same-type resource requests. It's a relatively simple heuristic, but great precision & recall for classifying scrapers vs. manual access.
Block:
You can't block a sufficiently determined expert scraper.
You can filter out a lot of scraping if that's a meaningful goal, but it's often not. A good strategy here is rate limiting + header inspection + CAPTCHA on high activity. Possibly add transfer quotas if you have a lot of large assets which might cause problems at low request rates.
This will deal with "script kiddies" and automated tools which account for the majority of cases where scraping could potentially impact the server's ability to respond to other users. It won't block researchers or other scrapers with more sophisticated skills.
I've seen people go wild here, to the point of silly things like displaying database record text as images. Complicated schemes generally impact UX for your routine users, while making it take slightly more time to write a scraper that's already "build once, use until the site is redesigned."
Since electric cars serve many / most of the same purposes, it makes sense to append them to a reward system which has already proven effective at driving adoption and retention of preferred behaviors.
It's scary, but often worth it.
* Typing speed turned out to rarely be a meaningful limit on my productivity with coding, writing, or general tasks.
* Using a nonstandard layout for my home desktop meant reconfiguring several laptops as well, then still having trouble any time I use any other computer.
Typing speed IS beneficial up to a point, but touch typing on QWERTY is already going to be near or past the point of diminishing returns for many users. It was fun to play with, but not worthwhile to do long-term. (YMMV)
No, really. Facebook is swimming with accounts for peoples' cats and dogs and iguanas and goldfish.
Ditto for Instagram, Twitter, etc. etc. etc. - people use the sites they're already using, and where their friends will see the posts.
One argument you'll hear a lot is that publishing the salary table is more fair to employees. Employers know what they're paying everyone, you don't, so they have more information than you during the hiring process.
The problem is, most of that information isn't relevant when you're negotiating salary. What's relevant is the market. Employees who have been at the company for a while, particularly in engineering, probably haven't been given raises and bonuses sufficient to keep up to what they'd make if they hopped jobs.
Publishing the salary table takes a nuclear option against the ability of employees to negotiate salary. "This is what we're paying everyone according to the formulas we use."
The ONLY party who benefits from open salary tables is the employer.
And really, they're shooting themselves in the foot, because they've just drastically shrunk their pool of potential hires. Particularly engineers. Even if potential hires love your company - they have bills, a family, career plans, aspirations to retire in a few years and start their own company.
And there are a lot of competing companies which would LOVE to negotiate a bit on salary in order to attract the talent they need.
* Businesses want to get spending in before the end of the year for tax & budget reasons.
* Customs surrounding holiday giving and charity, with disposable income from holiday bonuses.
So this is the best time of year for donation drives & matching programs.
The dominant factor here is going to be the rate at which the participants send and accept connection requests on Facebook. Some people send them to everyone they meet, some people never use Facebook.
KPI overfitting, yay!
(The best second-order effect is probably a multi-feature similarity measure between the participants and the person's current Facebook Friends, including graph distance to current Friends. In case anyone is taking a run at this.)
https://www.coursera.org/course/datasci
The one thing I'd really change is to tighten up the range of tools used. It seems helpful to show students a range of tools, but it usually ends up being a major distraction for students and a lot of extra effort for course staff. Any such course is already going to be a blitz of new concepts and technology.
Go full Python, plus interactive tools as helpful (Weka, Tableu). Let them pick up R or D3.js or whatever later, after they have a better appreciation for the concepts and such which make them useful.
Consider the Netflix Prize, where the most effective algorithm couldn't actually be used in production. Commercial applications tend to favor "good enough" classification with low computational complexity.
> It's almost a joke in the AI field: as soon as you produce a system that actually works, people say "Oh that's not AI, that's just math."
I think that's the standard "insert joke here" any time someone has a "What is AI?" slide.