What is the position? Is it to fill a chair? Is it to produce one-off work? Or is it to produce a larger project that's maintainable for the long term?
It's not simply enough to have some skill: for every bit of skill a person brings to the team, there is the additional overhead of communication with that person. After a point, adding more people to a project is simply not productive and even a hindrance, regardless of the calibre of those people. A small number of great programmers can often outperform a large team, and cost a lot less in salary and benefits.
If someone is 5/10 skilled, that person should spend time to get better at something. Read more books. Watch more talks. Study algorithms, design patterns, anti-patterns, etc. Write more code. Get good at something. I'm not a good C programmer. I like C, but I've never done enough to get good at it (maybe someday). But I built a distributed, fault-tolerant auto-scaling LNMP stack that services thousands of API requests per second, without a rearchitecture, because I studied how to scale and wrote scaling into the system from day one.
Embedded software experience is an in-demand skill. Many programmers can create bloated, slow code, but few can write lean, efficient, and fast code. That's highly valued in the embedded space, of course, as it's needed, but it's also very in demand at scale, because being inefficient costs a lot of money. If I were hiring, I'd look very fondly at someone with this skill, much more than someone who is focused on simply the language de jour. It's easy to find people who can produce code. It's hard to find people who can solve problems well.
I can't speak for every area, but in my locale there are plenty of hardware-oriented startups that have a tough time finding qualified people. The jobs are out there, but I agree the market is smaller than for pure software. One place hardware companies struggle is writing good drivers and application software. Someone who got good at that, along with having the embedded knowledge, would be very in demand.
If building rail line from western Alaska to connect to the continental system, no significant mountain ranges need to be crossed. Assuming the rail lands at the closest point across the Bering Straight, there is an almost flat route following the Koyukuk and Yukon Rivers over to the Mackenzie River. The North American rail network reaches as far as Hay River, near the south end of the Mackenzie River.
For a shorter route, the Tanana River could be followed past Fairbanks, and the route could continue paralleling the Alaska Highway to Whitehorse. At Whitehorse it could travel next to Teslin Lake and over land to Dease Lake. While Dease Lake is not currently connected to the continental rail network, but the track bed had been fully prepared in the 1970's, and it would be easy to install the necessary bridges and rail.
You're blaming railroads for a lot of things they have no control over:
Railroads don't classify the goods being shipped, shippers do.
Railroads can't refuse to take dangerous goods. They're classified as common carries and have to carry anything that's allowed by regulation, including hazardous materials.
Railroads do own older, less safe equipment, such as older DOT-111 tank cars and can reasonably be blamed for spotting the cars they own to industries shipping volatile chemicals. However, they cannot refuse to move cars delivered from other railroads, or leased by the industries. Furthermore, the factories making replacement vehicles are backed up for two years. Even so, railroads are replacing the cars they own. They are being responsible.
Most rail lines were built in rural areas, and the cities grew up around them. Don't blame the railroad when a city builds up next to a transportation corridor that transports dangerous goods. In the cases where railroads have rebuilt outside of cities, the cities have again crowded around the lines. What do you expect railroads to do? They were there first.
The solution is to put hydrocarbons (and other dangerous liquid goods) in pipelines that are statistically far safer. Pipelines, carrying one a single product, can be routed far away from urban areas. But those in power refuse to allow it, in cases stalling for over half a decade.
Railroads can be blamed for runaway trains, like the one that got away in Lac-Megantic (a train that had safely passed through Toronto earlier). Derailments happen, despite the best efforts to prevent them (they cost a lot of money, so no railroad wants them). But most of the blame for the explosive situations that have resulted cannot be placed on the railroads: their hands are tied.
Load following with a nuclear plant isn't difficult if you can easily control the moderator. This can be controlled by computer. In designs with large negative temperature coefficients (such as LFTR) the reaction speed can be controlled by the rate heat is removed from the reactor, making load following is as simple as controlling the speed of a pump in a coolant loop. Most (all?) current commercial reactors are not designed to habitually operate this way.
Commercial reactors are usually run full power for capital cost recovery reasons. The cost of fuel for nuclear versus the capital cost of current reactors is such that it is always cheaper than the fuel (or storage) for alternative power generation, so in periods of low demand, nuclear wins. Capital costs are high because it is difficult to handle high pressure water (and the 1700 fold expansion in volume if containment is lost) in current commercial designs. Designs using molten salts operate at atmospheric pressure and will be dramatically cheaper to construct. Companies such as Terrestrial Energy and Flibe Energy are working on commercialization of molten salt reactors, which are feasible from megawatts to gigawatts. Such a reactor would be ideal for a remote research base.
Why use the Zend engine at all?
on
The New PHP
·
· Score: 3, Interesting
Many of the problems with PHP are from the crappy language implementation. I recently came across a Java implementation of the language. It's been around forever, but as I hadn't heard of it, I figure many people reading this thread haven't either. It's Quercus. It's certainly worth a look as a Zend alternative.
Cheap multicopters have come a long way. While battery life is still a concern, hovering in strong winds is not. Combine that with an anti-vibration system and get very smooth imaging.
The battery issue is solved by using aeroplanes, which use far less energy to stay airborne, and instead of hovering, circling the target.
Easily through airplane skins, which are usually constructed of light materials. Cosmic rays are all over the x-ray and gamma spectra, and while you will absorb some, most of the very high energy gamma cosmic rays will pass right through you. However, the increased radiation is easily detectable.
I've used Radioactivity Counter and it works quite well. With a Galaxy Nexus phone, it's about as sensitive to gamma as my GammaScout. Watch review, or see it in action on a Chernobyl fuel fragment. But I wouldn't make a habit of exposing a CCD camera to ionizing radiation, because it will damage it.
One time I was taking a jump on my bike at 25 km/h, but was off balance and landed on my side, including the side of my head, at the same speed in rocks and packed dirt. I still have my left ear because I was wearing a helmet.
On the higher side of things, you find ridiculous and exotic offerings like the Yoga 2 Pro with a 13.3" LCD that has a 3200x1800 resolution (hint: you can't read anything at all unless you squint)
I wish I could have found a laptop like that when I bought a XPS 13 Developer Edition with the 1080p display in a 13 inch form factor, giving 169 DPI. It was the only Linux-compatible laptop I could buy with reasonable pixels for the screen size. The 275 DPI display of the Yoga 2 Pro would pack 63% more pixels in and allow me to adjust my fonts 40% smaller. I still see the pixels in my current display at 18" away from the screen, especially on curved letters, and it's the lack of pixel density getting in the way of smaller fonts. A 300 DPI laptop would be wonderful!
In my experience, using public DNS has solved far more problems. Quite often ISP DNS servers are slower to respond, do nasty things like wildcard unresolvable addresses to some dumb search page, and, as you mention, cause CDN requests to be directed to overloaded and bandwidth starved edge servers (and the YouTube CDN in particular when the ISP has its own video service...).
Since Bitcoin is deflationary, it makes more sense to stockpile (or hoard) it than to spend it. That is also what makes it more like a commodity than a currency.
But what is the point of stockpiling something if you never intend to use it? You're making the same argument as waiting until next year to buy a computer because it will be cheaper, but for some reason people buy computers anyway. At some point the holder of Bitcoins will value whatever can be bought with those Bitcoins more than the Bitcoins and an exchange will happen -- with another person who values Bitcoins more for what can or could be bought with them at a later date. Bitcoins are a de facto currency, regardless of what anyone wants them to be.
Call me a skeptic all you want, but I'm telling you, if you put your money into Cobalt60 now, you'll be lucky to even have half five years from now. The value of the USD may be eroding, but not at 13% per year! Stay away from it like it were radioactive!
Coins are old school. The future is in gaseous money! And you'll like this: it's also blue! That's right friends, the future is Iodine131! You can't spend it fast enough! There is so much demand for it that you can't keep it around! Not only that, it doesn't weight down your pockets like Cobalt60, no, you can keep it in your lungs!
I was just about to post that video. A summary from the YouTube video description:
12 things to prevent colony collapse disorder:
#1 general approach: use organic practices #2 general approach: strengthen bee immune system instead of "attack and kill" what nature uses to remove weak bees #3 don't use insecticide (for mite control or any other insect problem) inside of hives - bees are insects! #4 allow bees to create their own cell size (typically smaller) - no more pre-made foundation or cells #5 genetics based on "survival of the fittest" is superior to genetics resulting from mass production where the weak are medicated #6 swarming is the natural way to good genetics #7 local bees have adapted to challenges in your area #8 stop moving hives #9 feed bees honey, not sugar water #10 feed bees polyculture blossoms, not monoculture #11 stop using insecticides on crops - bees are insects! #12 raise hives off the ground
The Fairview Terminal in Prince Rupert, BC, is undergoing expansion and will be able to handle those ships. It's not in the US, but it's much closer sailing and it's connected to the continental railway network over the lowest (shallowest grade) railway pass (Yellowhead) over the Rocky Mountains.
The one other thing I missed is to also think of designing a service oriented architecture. Every role that your system has, such as authentication (I'd use OAuth2), should be its own service. By using clearly defined APIs, it will make it easier to replace pieces of your system with new ones (even written in new languages), and it will give you an interface to write tests against for your tests.
As someone who has written an application that scales to over 1 billion requests per day, let me offer my thoughts.
Scaling your application should be as trivial as launching more application server nodes. If you can't add/remove application nodes painlessly, you've probably done something wrong like keep state on them (this includes sessions).
Don't worry about scaling your application layer at all (within reason). You can always throw more machines at the application side in a pinch, and for a long while it will be cheaper to add servers than to hire someone. When your application servers are costing you more than a salary, hire someone to find the hotspots in the code and make them faster. Until then it's a waste of your time.
Scaling state, aka your datastores, is where the challenge lies. You need to spend a large amount of time sitting down and analysing every operation you plan to do with your data. SQL is great for a lot of things, but you will eventually run into a point where heavy updates make SQL difficult to scale. Mind you, decent hardware (lots of cores, RAM, and SSD) running MySQL should scale to several thousand active users if your queries are not expensive. The Galera patches to MySQL (incorporated into Percona XtraDB Cluster and MariaDB) can give you true high-availability, but you will still have write-throughput limitations.
I would also highly recommend you look into Cassandra (especially 1.2+, with CQL 3), which was built from the ground up to scale thousands of low end machines that often fail (if you can't tolerate hardware failure, you messed up). Cassandra is more limited in the kinds of queries you can execute, more relaxed with data consistency, and more thought is needed ahead of time. On the other hand, it can also be used for global replication, which is something you are interested in. At the very least, having a good understanding of its data and query model will open your mind to the kinds of tradeoffs that must be made to enabling scaling.
Contrary to what others are saying, you are correct to think about scaling now before you even start! Doing a rewrite is costly and expensive in money and time. Why set yourself up for that? Planning for scale before you start is the best time! If you start with a scalable datastore like Cassandra, and structure all your queries to work within its model, it is no more work than doing things in SQL, and you're way ahead of the game!
The most important part is spending time modeling how you will access your data. Think about how you'll avoid hot spots (which make scaling writes difficult), and think about how to make reads fast by reading as little as possible. Think about caching, and how you'll invalidate the cache of a piece of your data without having to invalidate caches for things that didn't change. (Think about updating on data ingestion instead of running statistics later.) If you can't avoid hot spots, make only small reads, and cache independently, you are not done.
Slashdot Mirror
What is the position? Is it to fill a chair? Is it to produce one-off work? Or is it to produce a larger project that's maintainable for the long term?
It's not simply enough to have some skill: for every bit of skill a person brings to the team, there is the additional overhead of communication with that person. After a point, adding more people to a project is simply not productive and even a hindrance, regardless of the calibre of those people. A small number of great programmers can often outperform a large team, and cost a lot less in salary and benefits.
If someone is 5/10 skilled, that person should spend time to get better at something. Read more books. Watch more talks. Study algorithms, design patterns, anti-patterns, etc. Write more code. Get good at something. I'm not a good C programmer. I like C, but I've never done enough to get good at it (maybe someday). But I built a distributed, fault-tolerant auto-scaling LNMP stack that services thousands of API requests per second, without a rearchitecture, because I studied how to scale and wrote scaling into the system from day one.
Embedded software experience is an in-demand skill. Many programmers can create bloated, slow code, but few can write lean, efficient, and fast code. That's highly valued in the embedded space, of course, as it's needed, but it's also very in demand at scale, because being inefficient costs a lot of money. If I were hiring, I'd look very fondly at someone with this skill, much more than someone who is focused on simply the language de jour. It's easy to find people who can produce code. It's hard to find people who can solve problems well.
I can't speak for every area, but in my locale there are plenty of hardware-oriented startups that have a tough time finding qualified people. The jobs are out there, but I agree the market is smaller than for pure software. One place hardware companies struggle is writing good drivers and application software. Someone who got good at that, along with having the embedded knowledge, would be very in demand.
If building rail line from western Alaska to connect to the continental system, no significant mountain ranges need to be crossed. Assuming the rail lands at the closest point across the Bering Straight, there is an almost flat route following the Koyukuk and Yukon Rivers over to the Mackenzie River. The North American rail network reaches as far as Hay River, near the south end of the Mackenzie River.
For a shorter route, the Tanana River could be followed past Fairbanks, and the route could continue paralleling the Alaska Highway to Whitehorse. At Whitehorse it could travel next to Teslin Lake and over land to Dease Lake. While Dease Lake is not currently connected to the continental rail network, but the track bed had been fully prepared in the 1970's, and it would be easy to install the necessary bridges and rail.
Still, ships would be more efficient.
You're blaming railroads for a lot of things they have no control over:
The solution is to put hydrocarbons (and other dangerous liquid goods) in pipelines that are statistically far safer. Pipelines, carrying one a single product, can be routed far away from urban areas. But those in power refuse to allow it, in cases stalling for over half a decade.
Or blame the shippers, who purposely make their shipments more volatile and mislabel the contents.
Railroads can be blamed for runaway trains, like the one that got away in Lac-Megantic (a train that had safely passed through Toronto earlier). Derailments happen, despite the best efforts to prevent them (they cost a lot of money, so no railroad wants them). But most of the blame for the explosive situations that have resulted cannot be placed on the railroads: their hands are tied.
Load following with a nuclear plant isn't difficult if you can easily control the moderator. This can be controlled by computer. In designs with large negative temperature coefficients (such as LFTR) the reaction speed can be controlled by the rate heat is removed from the reactor, making load following is as simple as controlling the speed of a pump in a coolant loop. Most (all?) current commercial reactors are not designed to habitually operate this way.
Commercial reactors are usually run full power for capital cost recovery reasons. The cost of fuel for nuclear versus the capital cost of current reactors is such that it is always cheaper than the fuel (or storage) for alternative power generation, so in periods of low demand, nuclear wins. Capital costs are high because it is difficult to handle high pressure water (and the 1700 fold expansion in volume if containment is lost) in current commercial designs. Designs using molten salts operate at atmospheric pressure and will be dramatically cheaper to construct. Companies such as Terrestrial Energy and Flibe Energy are working on commercialization of molten salt reactors, which are feasible from megawatts to gigawatts. Such a reactor would be ideal for a remote research base.
Many of the problems with PHP are from the crappy language implementation. I recently came across a Java implementation of the language. It's been around forever, but as I hadn't heard of it, I figure many people reading this thread haven't either. It's Quercus. It's certainly worth a look as a Zend alternative.
Thank you for that :)
Since slashdot is now run by marketing, why not let them know about the beta where they might listen? Slashdot Media on LinkedIn.
Cheap multicopters have come a long way. While battery life is still a concern, hovering in strong winds is not. Combine that with an anti-vibration system and get very smooth imaging.
The battery issue is solved by using aeroplanes, which use far less energy to stay airborne, and instead of hovering, circling the target.
One could say It matters so little it antimatters.
Easily through airplane skins, which are usually constructed of light materials. Cosmic rays are all over the x-ray and gamma spectra, and while you will absorb some, most of the very high energy gamma cosmic rays will pass right through you. However, the increased radiation is easily detectable.
I've used Radioactivity Counter and it works quite well. With a Galaxy Nexus phone, it's about as sensitive to gamma as my GammaScout. Watch review, or see it in action on a Chernobyl fuel fragment. But I wouldn't make a habit of exposing a CCD camera to ionizing radiation, because it will damage it.
One time I was taking a jump on my bike at 25 km/h, but was off balance and landed on my side, including the side of my head, at the same speed in rocks and packed dirt. I still have my left ear because I was wearing a helmet.
I wish I could have found a laptop like that when I bought a XPS 13 Developer Edition with the 1080p display in a 13 inch form factor, giving 169 DPI. It was the only Linux-compatible laptop I could buy with reasonable pixels for the screen size. The 275 DPI display of the Yoga 2 Pro would pack 63% more pixels in and allow me to adjust my fonts 40% smaller. I still see the pixels in my current display at 18" away from the screen, especially on curved letters, and it's the lack of pixel density getting in the way of smaller fonts. A 300 DPI laptop would be wonderful!
In my experience, using public DNS has solved far more problems. Quite often ISP DNS servers are slower to respond, do nasty things like wildcard unresolvable addresses to some dumb search page, and, as you mention, cause CDN requests to be directed to overloaded and bandwidth starved edge servers (and the YouTube CDN in particular when the ISP has its own video service...).
But what is the point of stockpiling something if you never intend to use it? You're making the same argument as waiting until next year to buy a computer because it will be cheaper, but for some reason people buy computers anyway. At some point the holder of Bitcoins will value whatever can be bought with those Bitcoins more than the Bitcoins and an exchange will happen -- with another person who values Bitcoins more for what can or could be bought with them at a later date. Bitcoins are a de facto currency, regardless of what anyone wants them to be.
Call me a skeptic all you want, but I'm telling you, if you put your money into Cobalt60 now, you'll be lucky to even have half five years from now. The value of the USD may be eroding, but not at 13% per year! Stay away from it like it were radioactive!
Coins are old school. The future is in gaseous money! And you'll like this: it's also blue! That's right friends, the future is Iodine131! You can't spend it fast enough! There is so much demand for it that you can't keep it around! Not only that, it doesn't weight down your pockets like Cobalt60, no, you can keep it in your lungs!
I was just about to post that video. A summary from the YouTube video description:
You are not alone. I've spent more on games in the last 2 months than I had in the prior 15 years. All thanks to Steam on Linux.
Oh Sn-ap!
Hey man, it's funny if you look on the lighter side.
The Fairview Terminal in Prince Rupert, BC, is undergoing expansion and will be able to handle those ships. It's not in the US, but it's much closer sailing and it's connected to the continental railway network over the lowest (shallowest grade) railway pass (Yellowhead) over the Rocky Mountains.
The one other thing I missed is to also think of designing a service oriented architecture. Every role that your system has, such as authentication (I'd use OAuth2), should be its own service. By using clearly defined APIs, it will make it easier to replace pieces of your system with new ones (even written in new languages), and it will give you an interface to write tests against for your tests.
As someone who has written an application that scales to over 1 billion requests per day, let me offer my thoughts.
Scaling your application should be as trivial as launching more application server nodes. If you can't add/remove application nodes painlessly, you've probably done something wrong like keep state on them (this includes sessions).
Don't worry about scaling your application layer at all (within reason). You can always throw more machines at the application side in a pinch, and for a long while it will be cheaper to add servers than to hire someone. When your application servers are costing you more than a salary, hire someone to find the hotspots in the code and make them faster. Until then it's a waste of your time.
Scaling state, aka your datastores, is where the challenge lies. You need to spend a large amount of time sitting down and analysing every operation you plan to do with your data. SQL is great for a lot of things, but you will eventually run into a point where heavy updates make SQL difficult to scale. Mind you, decent hardware (lots of cores, RAM, and SSD) running MySQL should scale to several thousand active users if your queries are not expensive. The Galera patches to MySQL (incorporated into Percona XtraDB Cluster and MariaDB) can give you true high-availability, but you will still have write-throughput limitations.
I would also highly recommend you look into Cassandra (especially 1.2+, with CQL 3), which was built from the ground up to scale thousands of low end machines that often fail (if you can't tolerate hardware failure, you messed up). Cassandra is more limited in the kinds of queries you can execute, more relaxed with data consistency, and more thought is needed ahead of time. On the other hand, it can also be used for global replication, which is something you are interested in. At the very least, having a good understanding of its data and query model will open your mind to the kinds of tradeoffs that must be made to enabling scaling.
Contrary to what others are saying, you are correct to think about scaling now before you even start! Doing a rewrite is costly and expensive in money and time. Why set yourself up for that? Planning for scale before you start is the best time! If you start with a scalable datastore like Cassandra, and structure all your queries to work within its model, it is no more work than doing things in SQL, and you're way ahead of the game!
The most important part is spending time modeling how you will access your data. Think about how you'll avoid hot spots (which make scaling writes difficult), and think about how to make reads fast by reading as little as possible. Think about caching, and how you'll invalidate the cache of a piece of your data without having to invalidate caches for things that didn't change. (Think about updating on data ingestion instead of running statistics later.) If you can't avoid hot spots, make only small reads, and cache independently, you are not done.
Good luck!
Even the high reading of 2.9 microsieverts/hour in that video isn't that bad for a short duration.
The naturally radioactive beaches of Guarapari, Brazil are 10-15 times hotter than that: http://www.youtube.com/watch?v=RvgAx1yIKjg
Even in a large plane passengers make up a significant percentage of the total flying weight. Airline companies just average the cost.