> To clarify, I don't think it's a coincidence and I think Google employees probably submitted these.
If you look at the posters' profiles you can see where they both work. (Neither is currently a Google employee.)
414 karma · joined October 31, 2011
If you look at the posters' profiles you can see where they both work. (Neither is currently a Google employee.)
My personal favorite is Nu[1] with Nutronic[2], though you can do similar things with MacRuby and PyObjC.
Is there any possible outcome to your question that would serve any purpose other than to rile the parent poster?
You should use your user page[1] to draw attention to the things you think are most important.
> Additionally, if I fork a project, it's likely just so that I can add a fix and issue a pull request, that's additionally something I don't think people need to see.
I disagree. Finding your way around a foreign code base enough to make the changes you need is an essential skill for a developer. Repositories you've forked and made pull requests for are a great way to demonstrate that.
It's better for me because it works when I'm on an airplane, that's all. If you do all of your development where the test database is accessible, then there's little to no benefit.
> The fear of running unit tests in production is that someone screwed up the testing configuration and your database writes are no longer happening on a mocked SQLite connection, but hitting the live database. Oops!
I Agree. Unit tests should never be run in or near production systems. The whole purpose of the tests is predicated on the assumption that your code is broken. Do you really want to bring broken code near customer data?
[1] http://docs.python.org/library/parser.html
Objective-C, when used like Objective-C and not just C-with-classes, is a lot like Ruby. Both have a shared heritage in Smalltalk.
That said, Opacity's development has slowed to a crawl. If the gentleperson(s) behind PaintCode keep it up, they will surely surpass it very soon.
Since approximately the 1st of May, 2008[1]. Adobe publishes a specification of the file format[2], currently at version 10[3]. N.B. The Wikipedia entry suggests[4] that the specification does not exhaustively cover the capabilities of the format.
[1] http://www.adobe.com/aboutadobe/pressroom/pressreleases/2008...
[2] http://www.adobe.com/devnet/swf.html
[3] http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/e...
I do a lot of cross-platform integration. This is based on my experience. If you know you're going to cover multiple platforms from the beginning, you will do a lot of things to make that a lot easier.
Most of those would be written to target a graphics framework (like OpenGL) for the visual elements. Then, for each platform there will be a host that OS-specific things like file & network access. You can also use libraries to abstract that for you.
So the amount that needs to be rewritten depends on how similar the new platform is to the old ones. Going from PC to iOS would be about 40%. Going to Nintendo Wii, maybe 70%.
Unless the platform is particularly unusual, most of the hard problems were solved in the first release, adding additional platforms is fairly mechanical. So even if you need to replace >50% of the code, you know roughly how you're going to do it before you start.
One recommendation: https://github.com/kikito
I saw the problem with Firefox 10 on CentOS. My default font was specifically configured to Bitstream Vera Serif.
Setting the default font in the Preferences seems to only change it for the encoding in the active tab (unless you go into the Advanced dialog). For several Asian languages it wanted to use "serif", which appears to be the 20-year-old X11 default version.
Complexity is the difference.
Hypervisors "won" because it was easier to implement; They only had to add another layer to the stack, rather than fundamentally change the structure of the OS.
The outcome is a more baroque collection of code, though. Worse truly is better.
In my case that was much uglier, and I had to fix it to read the page.
If I were a painter, I would paint me the hell out of some van Gogh. In every skill I've practiced seeing what the masters do, reproducing it (especially figuring out _why_ they did it that way) has been a very useful learning technique.
More to the point of your post, and this story: Would I sell my van Gogh copies? Probably not. Not because I think there's something terribly wrong about it. Mostly because they'd still be inferior to the original.
I would certainly give them away to friends who wanted to hang it in their den or library, though.
In the long term, Bitcoin might be a viable alternative. It really hinges on the adoption of cellphone applications for exchanging them, I think.
In the short term, though, cash is king. If they stop printing paper kronor in Sweden, then the underground will start using somebody else's paper, be that NOK or USD.
As an example, I'd guess there are areas in Mexico where you can get by entirely in USD, because there's so much of it there.
That system is "hawala"[1]. The Somalian diaspora (caused by perpetual civil war) is spreading the institution into many countries where it's not been practiced historically.
I suspect he's using the word "professional" here in the more traditional form. He's roughly referring to careers like doctor, lawyer, banker, where there is usually formal licensing based on public interest.
That's e.g. why there is a lot more paperwork to file when you start a hospital or a bank than a widget shop.
This is incorrect in a minor, but fundamentally important way, I think:
Apple does nothing to prevent you from selling outside their store. What they've done is make it difficult for the average iPhone owner to buy from you.
You need to target a specific demographic that can overcome those obstacles and will pay enough to make it worth your time.
In practice, that probably means enterprise.
If I have a task that could be made easier by having ImageMagick, but I don't have it on any machine I have easy access to, then I have to deal with the overhead of getting the package, installing the package, configuring the package, and possibly removing the package when I'm done.
Even though I know how to do all things, it would take me some time to get it all done, and then I'd have to waste brainpower in those things, and not the real problem I'm trying to solve.
A lot of that is solved by the "better" distributions, e.g. Debian has nearly everything under the sun.
But not everything. That's where the opportunity might be.
I probably wouldn't pay a dollar a month just for ImageMagick, but I might pay a few for shell access to a machine that has all of the new and shiny things available, things too new to get into the main repositories, and keeps them up-to-date and keeps adding new stuff, so I don't have to handle the sysadmin tasks for yet-another-box.
I suspect it won't take them very long to sell those copies after this announcement.
I still wear a watch but check the time on my cell phone probably 50%. The watch has become mostly just a functional piece of jewelry.
Do you have any examples of big libraries where "they could improve the documentation" is untrue? I can't think of any offhand.
(This is not snark. I'm honestly interested if you do.)
APIs are perpetually under-documented, in my experience, so the parent comment's observation is essentially an empty statement.