ProblemFactory

On OSX there is the fantastic http://postgresapp.com/ . It installs into /Applications so it is easy to remove, and comes with a start/stop GUI and taskbar icon. Great for local development.

But installing and configuring Postgres "properly" on a server is still something of a challenge. Do I need to modify random_page_cost on a SSD or not? What are good memory limits on modern big servers? What exactly needs to go into pg_hba.conf?

None of these seem too difficult after reading a few tutorials and wikis, but it would be nice if the server set itself up with reasonable defaults based on the machine its running on.

The Risks sections are always like that. Any advertisements for stocks must have disclaimers about a wide range of possible risks, and that despite promising historical data you could lose your entire investment. Otherwise they could face expensive lawsuits when future shareholders claim that they were misled and not informed of these risks.

For example from Facebook's S-1: "Growth in use of Facebook through our mobile products, where we do not currently display ads, as a substitute for use on personal computers may negatively affect our revenue and financial results.", "We expect our rates of growth will decline in the future."

Google's S-1: "We expect our growth rates to decline and anticipate downward pressure on our operating margin in the future.", "We are susceptible to index spammers who could harm the integrity of our web search results.", "New technologies could block our ads, which would harm our business."

If it's a time-based contract, then testing and bug-fixing is part of the billable time - it's a normal part of development. The client can decide how much testing and bug-fixing they want, often there is a point where the software is considered good enough to stop spending more expense on it.

For fixed-fee contracts, I usually include testing and bug-fixing in the quoted price, and make sure to include the time spent on that in the estimates. There has to be a sign-off time limit though (for example 1-2 months), during which the client is supposed to test the software to their satisfaction and after which newly discovered bugs are not included - otherwise a project can linger on forever in your schedule.

However with fixed-fee contracts the main difficulty is agreeing on what are bugs, and what are change requests if the initial plan was not detailed enough.

If he takes the job, then this is certainly wise. But it is still most likely a bad idea to take the job.

* As an undergrad on summer internships, and in your first few years of professional work, it is better to optimise for learning rather than earning. A project where you work alone with unfamiliar technology at a non-software company won't provide that. He should instead find a software company with a culture of strong mentoring and code reviews.

* It's possible to learn Android, iOS or web development over a summer if you have some previous C++ development experience. But learning all three, and designing and building a reasonable quality app on two platforms + a server backend is just not feasible. The end result will be poor, and the client will not realise that this was because of their own unrealistic expectations. As a result, OP may not get a great reference to use after graduating.

I mean, if the other alternatives are fast food jobs, then sure. But he needs to manage the expectations of the employer very carefully - maybe proposing a mobile website only, no native or hybrid apps for the first version.

It seems surprising that the architecture is spread over so many different service providers. CDN from Fastly, servers from Rackspace, file storage on AWS, database from Heroku, ElasticSearch from Elastic, log storage on Dreamhost, DNS from Dyn etc.

It seems like a lot of accounts and effort to manage all these, while AWS, Rackspace and Heroku could host most of the required parts on their own.

Is there a technical reason for using each of these services from these providers? Or is it just easier to get smaller donations from multiple supporters than all from one source?

The problem for Github was that the best place to "keep backups yourself" was Bitbucket. I archived a number of inactive projects from Github to Bitbucket. But that gets tedious, so why not start them on Bitbucket in the first place?

> But I'd appreciate if their PR department didn't expect us to swallow this as a positive change.

I don't have any numbers on how people structure their accounts on Github, but my feeling is that this is a positive change for the majority of Github users.

Git encourages having many smaller repos for modules over massive single repos. $1/repo/month is fine for active projects, but gets expensive really fast if you want to keep archives of small private experiments around. Because of the per-repo pricing on Github, I've seen many friends and startups I've worked with keeping their open-source public repos on Github (for free), while moving private repos to Bitbucket.

I would not be surprised if this pricing change would be a net revenue loss for Github, but still implemented to avoid losing market share to Bitbucket.

You are not spending 100% of your income, right? You only need to double or triple the income you spend on rent and living costs, not the portion left over for savings to keep the same standard of living.

That said, if you are earning $100k in Vilnius, then it will be extremely difficult to find a higher-paying employment offer relative to living costs anywhere in the world. Maybe you can make 1.5-2x that if you go to work in finance - but you will most likely need to move to some of the most expensive cities (Zurich, London, etc) in the world.

The typical way of increasing income as a freelancer, after maxing out the hourly rate on your own is to start a development company. Partner with 1-2 freelancer friends, and start taking on bigger projects. Hire a small team of junior developers, and bill out their time as well. Grow. Start taking on fixed-bid mid-sized enterprise and government projects.

But this can be a very tedious and soul-crushing change, especially at the stage where you have only a few junior developers on staff: you will need to move from doing actual development work to reviewing their code, and handling "management and sales".

If that doesn't sound like something for you, perhaps instead consider:

* Moving to somewhere with even lower cost of living than Vilnius. Hell, move to the next beach-front villa somewhere in Asia every 6 months.

* Be more picky about accepting work - optimise for how much fun they seem to be, not only the hourly rate.

> This rests on the VC assertion that Uber is playing a winner-take-all game.

They certainly seem to be playing a winner-take-all game, by heavily subsidising rides when they first launch in a new city.

But it seems questionable to conclude that taxi services really are a winner-take-all market. Many Uber drivers I see have multiple phones, running multiple taxi apps at the same time. And most people I know have at least two apps in their phone. I usually check three (Uber, an European one, and a local one in my city) before making an order.

There are some network effects to taxi services - customers want a car fast, and drivers want to find fares fast. But there are no switching costs for either side, so these network effects can be distributed over more than one platform.

Google I/O tickets are difficult to get - you apply, and they choose who can purchase a ticket by lottery.

One of the reasons for this is that they used to hand out swag worth more than the ticket price (latest Nexus phones, etc).

This makes sense for Google - increasing developer mindshare and experience on their platforms is worth more than the device cost. But this also had the effect of "everyone" applying for Google I/O to get the swag, even if you are not too excited about attending the talks.

In the release notes they mention that they will upgrade to Nginx 1.10 when it is released: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Nginx

That's true, but most of the time you can express the "new" stuff in terms of existing fast libraries.

I've had a few cases where you can't, and have become a big fan of Cython for that. It lets you add C typedefs to Python code, and then compile the module at import time. Example here: http://pastebin.com/sF8KmyiU

All of pure Python is still allowed in these modules, but the typedeffed variables become pure C variables instead of objects, and loops become pure C loops. For this particular function, I got a 1000x speedup compared to the original Python code.

In the end, this isn't Python any more - but it's close enough, and only needed for loops that run over millions of items.

Bluetooth audio works perfectly fine on OSX with some Sony BT headphones I recently got - even through a wall at 5+ meters.

But compatibility with C extensions is a major selling point.

25% speedup for pure Python code is not that appealing in numerical analysis code, when you can use NumPy, or sprinkle a few typedefs into a critical function and compile with Cython for a 1000x speedup.

If C extension compatibility is broken, then many Python programs will altogether still be slower, despite the pure python speedup.

It is probably a reference to the (in)famous launch review of iPod on Slashdot: https://slashdot.org/story/01/10/23/1816257/apple-releases-i...

> No wireless. Less space than a nomad. Lame.

You might enjoy http://www.stupidhackathon.com/

> Drivers are contractors, responsible for their own hourly wage. Sometimes they will earn below the minimum wage, and at other times, well above it.

Aren't all taxi drivers in most cities of the world also self-employed? Even with brand-name services, they just pay a fee to the taxi company to use their logo and dispatch.

Sure. But by forcing you to go through RDS even if you migrate X->RDS->Y, they are halfway there.

In the process you need to set up an AWS account, create a RDS database, import your data into it... and perhaps you stop there despite the initial plans. Or use RDS for your next project, since you are already more familiar with it.

Clever, but they could easily detect this on their servers.

Better handling of Unicode was also why Python3 adoption has been slow. Upgrading a library or project from Py2 to Py3 is very simple if you already handle bytes vs unicode carefully everywhere in your program.

But for projects that mix unicode and byte strings, and hope for the best (it works okay as long as it is ASCII or UTF8), the upgrade requires substantial work.

Most real-world contracts have a clause saying "if any part of this contract is ruled invalid, the rest stays in effect."

If you are getting funding, then you will certainly need a separate LLC. The agency will have many deals and contracts with people you have worked with, and the investors will want these to be separate from the actual product they are funding.

But it might be wise to wait until the funding is almost-confirmed before starting with this. The investors may also have specific requirements on where and how the LLC is registered, and you may need to do it over again if you do something else right now.

> The biggest thing is that people drive when they shouldn't.

It is extremely common to drive beyond your actual "in complete control" speed.

You are supposed to drive slowly enough in snow so that you can correct for unexpected patches of black ice or rocks in the snow slush. You are supposed to leave a long enough gap to be able to react and stop if the car in front of you unexpectedly fully slams on their brakes. You are supposed to drive slowly enough to stop if a kid runs out between parked cars.

Humans almost never do, because unexpected things almost never happen. Traffic flows faster and perhaps smoother, because we willingly accept driving at speeds where we can avoid most, but not all hazards.

But if we expect self-driving cars to always put safety first, then we will find them to be "tediously" slow, even if they have better sensors and faster reaction speed than us.

I'm using Fabric for the Twitter SDK on Android, and it is just the same there.

No, I don't want an IDE plugin that rewrites (read: messes up) my config files to "help" me install things. All I need is a website to generate API keys and a package URL to add to the dependencies file.

The IDE plugin must have taken quite a bit of effort as well - not sure why and how someone at Twitter considered it to be a good idea. Perhaps a misguided attempt at "capturing developer mindshare" or the arrogant assumption that Twitter/Fabric SDKs are important parts of people's apps?

There are converters, and it's not too difficult to even write code that runs in both Python 2 and 3.

The main roadblock in upgrades is unicode text vs bytes handling.

Python2 was lax about using bytes for text. You could do unicode and bytes properly if you really tried hard enough, but it took a conscious effort. So most people just used bytes for text, and hoped for the best (if the data is ASCII or UTF-8, it will work most of the time).

Python3 is strict about the text vs bytes separation. Patching this into a program afterwards is a lot of work.

But if your Python2 program already does unicode carefully in Python2 (unicode type internally everywhere, from __future__ import unicode_literals, explicit encode/decode when talking to external APIs), then you are 90% done with the upgrade to Python3.

> Who can prove that there was such a notice, long after the packaging is gone?

The notice does not matter. Patents cover not only manufacturing and sales, but also use of the invention. The patent owner does not need a contract with you, the patent law is enough.

If there exists a valid patent, and you don't have permission from the patent owner, then you technically are not allowed to use your widget regardless of what the packaging does or does not say or where you got it from.

They are not listed because the extra taxes are not levied by Estonia.

Almost every country in the world taxes their residents' income, even if it arrives from a company abroad. And US (in)famously taxes their citizens' income, even if they do not live in US.

So if you run a company remotely, you still have to check with your local tax rules to see how much tax you may need to pay if this company pays you salary or dividend.

No, and all scientists want everyone to find insights and come closer to truth.

But the reality is that both the career advancement and funding for further experiments is almost entirely based on the number of publications in prestigious journals.

And effort put into collecting data is not by itself publishable: you must add analysis, and very often analysis that successfully confirms a new hypothesis or invalidates previous beliefs to publish. Journals prefer to publish exciting results, and "we ran experiment X, and found no significant effects" is usually rejected.

Fixing this is desperately needed, but so far nobody has come up with a solution that would actually fix this.

A middle ground would be to require data publication after a certain time period. For example, NASA and ESA release original data 6-12 months after collection. Releasing original data together with the paper also works.

It's not just the batteries: heating the cabin takes considerable energy in -20C, but but the heat is "free" on fuel-burning engines.

Hopefully there will be more data available and released in the future, as Tesla and Nissan Leaf have been the best-selling cars in Norway for multiple years in a row.

For anecdata, an Uber driver with a Nissan Leaf told me recently that range on very cold days is about half of the summer range.

There is some discussion on why the Postgres team dislikes query hints here: https://wiki.postgresql.org/wiki/OptimizerHintsDiscussion

But perhaps I also have some practical advice to try.

I had a similar issue: I have a few tables with sensor data, 300-500 million rows, indexed among other things by event type. Some counting queries kept defaulting to full table scans. It turned out that this was because of limited statistics on the distribution of counts by event type.

The default_statistics_target config parameter sets how many entries Postgres keeps in the histogram of possible values per column, the default is 100 I think. Because my event types were not evenly distributed, the less frequent ones were missing from the statistics histogram altogether, and somehow this resulted in bad query plans.

As a fix, I upped the default_statistics_target to 1000, and to set it to 5000 for the biggest tables. Then after a vacuum analyze, the query planner started making sensible choices.

Another thing to try is perhaps reducing the random_page_cost config parameter from it's default of 4.0. On SSDs, random page costs are much closer to 1 than they are 4 (compared to long sequential reads).