I definitely agree with this - except for the fact that the typical hipster won't be in the woods. Although they'd likely get lost if in one.
Having a magnetometer, compass, and tie-in to Apple Maps so that there's augmented reality would be a great feature. Imagine setting what you want to go to on your iphone, put it in your pocket, and can navigate to your destination. Along the way, have some notifications (e.g. email/fb/etc), etc. as needed. Perhaps a Google Now like features?
come to think of it, having google now on a watch would be brilliant.
I'm still rather peeved at all of the changes to gmail. Since they announced that they wanted to force changes to the gmail UI, I stopped using g+, started to use duckduckgo, and blocked as many google scripts and sites as I possibly could.
Once I find a gmail alternative, they can basically kiss me and my family good bye.
25 columns, at 4 bytes per column, that's 100 bytes. I'm not sure how much overhead, but hopefully not much.
100 bytes at 2000 rows = 200,000 bytes. Across 32KB pages, that's 7 pages, allowing for 10% overhead. I assume that it's 40 Gb/sec IB, how many microseconds would that take to transfer?
As for the join, i guess if there is more details about the schema (i think there's a link to it buried somewhere), simple joins should be pretty quick. I agree that a poorly implemented optimizer producing a bad plan could result in a nested-loop join wasting a lot of cycles, what this article tells me is that this database is pretty much on par with a quality RDBMS from years ago, and nowhere near as fast as NoSQL databases of today.
k. This is slightly laughable. 33,500 rows? in 87 seconds? that seems glacial. And 1.23 seconds being the new speed? that seems as expected.
aside from comparing the speed of a Lada vs a common garden slug, how does this compare against other databases?
Yeah. This whole mindset with RIM is frustrating. I fail to understand why so many things are so secretive. E.g. the builds of their OS - Windows, iOS, etc. have betas available, but RIM keeps on keeping it a secret and having each carrier release it individually. And getting information on how to develop for the system is amazingly difficult. All of their hardware efforts are moot if they don't open up as a company, be able to take some criticism, and work with the development community to help them develop software.
Oh, providing a decent API helps too. Their secrecy has got to stop.
P.S. I don't think going Android is the way to go. If I want Android, I'd get HTC or Samsung. But I have my BB still because of the keyboard and the security still. Of course, I put the SIM card into the 'ol iphone occasionally.
The article is false and misleading. If I clean up a leaking 55gallon drum of mercury wearing a proper hazmat suit I can be exposed to less mercury then a can of tuna, but does that make it safe to dispose of in a landfill? Just because personal exposure to a spill is low doesn't mean they are landfill safe!
I don't quite follow the argument here. How did you go from a CFL light bulb to a drum of mercury? Unless, of course, you're comparing quantities. a few glasses of water per day would be good. One glass a day would be far too little. But if you drank, say, 10 gallons in a sitting, that is obviously going to be toxic. As is drinking a few glasses of DDH2O ("pure" water).
I want to know what I can look for on the packaging, to tell me that the lightbulb I'm buying has an acceptable warm-up time (5 seconds would be OK, I suppose)
Of course, this is opposed to the brightness of incandescent bulbs, right? Those old bulbs actually get dimmer with time. Obviously, you can't trust what you read on the box then, either.
don't have a source here, but i thought i read somewhere that the average can of tuna has more mercury than what's in a modern CFL.
So that makes it ok to use products which we KNOW will be disposed of improperly and thus will go into the food chain and eventually tuna 10 years from now will have even more mercury in it.
So 10 years from now, you will be able to say the same thing: a can of tuna has more mercury than a CFL. So use more CFLs.
It doesn't mean that CFLs are safe, it just means that there is a lot of mercury in tuna!
I think it means that you have better things to worry about. Like tailpipe emmissions.
Oops... I worked out the price in pence, then wrote that it was pounds. I thought it seemed a bit expensive. But you've worked out the cost for seven years.
haha. Yeah. I think the same way about my hot water tank - which is only "60%" efficient. The 40% of the energy that is lost, heats up my house! Although, maybe not in the most convenient of places..
24x7*365 = 61320 hours.
At 0.5W, that's 30660 Wh, or 30 kWh. Here, the cost of energy is about $0.11 per kWh, bringing the cost to about $3.xx to use that LED light 24x7 for a year.
Just what the heck is the electricity rate in the UK?!?!
I haven't bought bulbs that takes anything but seemingly instantaneous time to light up in ages.
As for the math - if a 40W bulb is replaced by a 9W incandescent, then 2x40W = 80W. But 3x 9W = 27W.
Seems like you're still saving a significant amount of power here.
I don't know where you buy your CFLs from, but the ones I have come on like any normal incandescent light build does. Also, there are ones that are coiled, and ones which have a normal glass covering - these typically have light filters which give off varying colours of light: I have soft light CFLs in the living room, but more cooler, white light CFL's in my workshop. Unless you looked closely, they appear just like normal incandescents. The difference being that instead of the bulb being HOT after some usage, it's just warm (ok. pretty warm, but still touchable.)
haha. Yeah, that's what i thought. I actually switch out my CFLs to incandescent lightbulbs in the winter in my study because it is warmer. The study is a pretty small room and the lamp is close to me so it works out alright. I don't know about using heat balls in a large space though:p
Age brings experience, but there's plenty of energetic younger folks out there who are great at PRETENDING to have experience. Sure, they have no clue what they're talking about half the time, but they always impress the management.
*sigh*
Haha. yep. I completely agree. There's a big difference between knowing the semantics of a language/paradigm/system and being able to know/understand the nuances of it. It's the nuances that will get you every time...
The difference between the computing industry and the other industries you mentioned is that computing is hundreds of years younger, and thus changing orders of magnitude faster.
Medicine comes the closest because of continuous research, so doctors are required to stay current with continuing education (they have to do this to maintain certification).
I have a huge problem with this. The computing industry is younger, but I don't think it's changing that much faster - a lot of "new" concepts are just recycled old concepts! Albeit wrapped slightly differently. E.g. are dumb terminals and thin clients that much different? What about, as someone else noted, worker threads and local storage? Is the concept of local storage much different than caching? And I distinctly recall being taught about threaded programming in the 1990s. The big difference now is that there is a lot more resources than before. So the current crop of applications don't really have to be developed with as much care as older code. More resources -> more resources to waste.
I would consider myself an early career developer, but i've seen a lot of good and bad code from old and new developers. And I find that it's more often the newer ones that tend to rush code and leave things incomplete.
The whole idea of LAMP is that it's an easy-to-learn, easy-to-deploy stack. Any competent developer should be able to learn this, quickly. Even if you could assign a "LAMP Competence Metric" (say a 0-10 scale) to a person, a competent developer who is a 2 in LAMP will be a 9 much more quickly than an incompetent developer who is currently a 6.
When I hire coders, I like to see how quickly they can understand a system via standard UML architecture diagrams. I like to see if they can implement a basic logic task using their choice of language, and I want that implementation to be straightforward, and I want it to use the coder's chosen language's foundation libraries instead of reinventing the wheel.
I also like to get a feel for how experienced they are in working with any of the various system development processes. (Hint: "What's that?" is a bad answer. Cowboy Coders are unwelcome at my company.)
Regarding testing basic computer science concepts, I like to ask candidates to differentiate one thing from another. For example, given your list of concepts ("BNF, data normalization, OOP, MVC"), I'd ask:
I'd show them a BNF for something simple and ask them to interpret it. (Honestly though, I haven't used the term BNF since college. Not sure why you care.)
What is the difference between a normalized and denormalized schema? In what situations might you use each?
What is the difference between OOP and procedural programming?
Can you please describe MVC and what problems it solves?
I like this approach a lot. We've hired people who scored off-the-chart in standardized tests, but were completely unable to work within our relatively regimented development environment. I think the key things are work ethic (it'll be great if they could demonstrate their work ethic in multiple situations professionally or not), and the ability to learn abstract concepts and then apply them. Whatever they don't know when they start the job, they will be able to pick up. That is, of course, you require someone to be productive right away.
I try not to ask "what is this?" or "define this" type of questions, but I try to ask problem solving questions to see their problem solving skills.
Why not? At least it shows that they read SOMETHING about database and organization. You don't have to agree with it, but at least there's some basis for not agreeing with it rather than repeating past mistakes.
What's the problem? Because a good programmer can find a perm position elsewhere. Unless, of course, you offer is heads and shoulders above anything else, all you're going to get from temp positions are the dregs.
Slashdot Mirror
I definitely agree with this - except for the fact that the typical hipster won't be in the woods. Although they'd likely get lost if in one. Having a magnetometer, compass, and tie-in to Apple Maps so that there's augmented reality would be a great feature. Imagine setting what you want to go to on your iphone, put it in your pocket, and can navigate to your destination. Along the way, have some notifications (e.g. email/fb/etc), etc. as needed. Perhaps a Google Now like features? come to think of it, having google now on a watch would be brilliant.
Amen!
I'm still rather peeved at all of the changes to gmail. Since they announced that they wanted to force changes to the gmail UI, I stopped using g+, started to use duckduckgo, and blocked as many google scripts and sites as I possibly could. Once I find a gmail alternative, they can basically kiss me and my family good bye.
25 columns, at 4 bytes per column, that's 100 bytes. I'm not sure how much overhead, but hopefully not much. 100 bytes at 2000 rows = 200,000 bytes. Across 32KB pages, that's 7 pages, allowing for 10% overhead. I assume that it's 40 Gb/sec IB, how many microseconds would that take to transfer? As for the join, i guess if there is more details about the schema (i think there's a link to it buried somewhere), simple joins should be pretty quick. I agree that a poorly implemented optimizer producing a bad plan could result in a nested-loop join wasting a lot of cycles, what this article tells me is that this database is pretty much on par with a quality RDBMS from years ago, and nowhere near as fast as NoSQL databases of today.
k. This is slightly laughable. 33,500 rows? in 87 seconds? that seems glacial. And 1.23 seconds being the new speed? that seems as expected. aside from comparing the speed of a Lada vs a common garden slug, how does this compare against other databases?
Yeah. This whole mindset with RIM is frustrating. I fail to understand why so many things are so secretive. E.g. the builds of their OS - Windows, iOS, etc. have betas available, but RIM keeps on keeping it a secret and having each carrier release it individually. And getting information on how to develop for the system is amazingly difficult. All of their hardware efforts are moot if they don't open up as a company, be able to take some criticism, and work with the development community to help them develop software.
Oh, providing a decent API helps too. Their secrecy has got to stop.
P.S. I don't think going Android is the way to go. If I want Android, I'd get HTC or Samsung. But I have my BB still because of the keyboard and the security still. Of course, I put the SIM card into the 'ol iphone occasionally.
I refuse to have my browser access my private info like that! Andreesen's company doesn't need to know my fb profile name or anything.
The article is false and misleading. If I clean up a leaking 55gallon drum of mercury wearing a proper hazmat suit I can be exposed to less mercury then a can of tuna, but does that make it safe to dispose of in a landfill? Just because personal exposure to a spill is low doesn't mean they are landfill safe!
I don't quite follow the argument here. How did you go from a CFL light bulb to a drum of mercury? Unless, of course, you're comparing quantities. a few glasses of water per day would be good. One glass a day would be far too little. But if you drank, say, 10 gallons in a sitting, that is obviously going to be toxic. As is drinking a few glasses of DDH2O ("pure" water).
I want to know what I can look for on the packaging, to tell me that the lightbulb I'm buying has an acceptable warm-up time (5 seconds would be OK, I suppose)
Of course, this is opposed to the brightness of incandescent bulbs, right? Those old bulbs actually get dimmer with time. Obviously, you can't trust what you read on the box then, either.
don't have a source here, but i thought i read somewhere that the average can of tuna has more mercury than what's in a modern CFL.
So that makes it ok to use products which we KNOW will be disposed of improperly and thus will go into the food chain and eventually tuna 10 years from now will have even more mercury in it.
So 10 years from now, you will be able to say the same thing: a can of tuna has more mercury than a CFL. So use more CFLs.
It doesn't mean that CFLs are safe, it just means that there is a lot of mercury in tuna!
I think it means that you have better things to worry about. Like tailpipe emmissions.
Oops... I worked out the price in pence, then wrote that it was pounds. I thought it seemed a bit expensive. But you've worked out the cost for seven years.
24h*365 = 8760h 8760h*0.0005kW = 4.38kWh. £0.14/kWh * 4.38kWh = £0.61.
(The 9W CFL would be £11, the 40W incandescent £50.)
Seven years? Crap. ok. no more math for me! Back to writing design specs....
haha. Yeah. I think the same way about my hot water tank - which is only "60%" efficient. The 40% of the energy that is lost, heats up my house! Although, maybe not in the most convenient of places..
24x7*365 = 61320 hours. At 0.5W, that's 30660 Wh, or 30 kWh. Here, the cost of energy is about $0.11 per kWh, bringing the cost to about $3.xx to use that LED light 24x7 for a year. Just what the heck is the electricity rate in the UK?!?!
oh, and we use the electroluminscent strips to keep the hallways lit. it IS on 24x7, but they use a lot less energy.
I'm in Canada, so it gets cold. But I don't think I let my bedroom get down to 5C though - high single digits before the thermostat kicks in at night.
it's still a lot of mercury in the landfills.
I don't have a source here, but i thought i read somewhere that the average can of tuna has more mercury than what's in a modern CFL. Hmm. or was it here: http://green.yahoo.com/blog/the_conscious_consumer/70/three-cfl-myths-busted.html
I haven't bought bulbs that takes anything but seemingly instantaneous time to light up in ages. As for the math - if a 40W bulb is replaced by a 9W incandescent, then 2x40W = 80W. But 3x 9W = 27W. Seems like you're still saving a significant amount of power here.
I don't know where you buy your CFLs from, but the ones I have come on like any normal incandescent light build does. Also, there are ones that are coiled, and ones which have a normal glass covering - these typically have light filters which give off varying colours of light: I have soft light CFLs in the living room, but more cooler, white light CFL's in my workshop. Unless you looked closely, they appear just like normal incandescents. The difference being that instead of the bulb being HOT after some usage, it's just warm (ok. pretty warm, but still touchable.)
haha. Yeah, that's what i thought. I actually switch out my CFLs to incandescent lightbulbs in the winter in my study because it is warmer. The study is a pretty small room and the lamp is close to me so it works out alright. I don't know about using heat balls in a large space though :p
.. over my iphone..and putting off getting an Android. The BB may be clunky, but I've a lot more confidence in it (so far) than iOS4/iPhoneOS 3.
Age brings experience, but there's plenty of energetic younger folks out there who are great at PRETENDING to have experience. Sure, they have no clue what they're talking about half the time, but they always impress the management.
*sigh*
Haha. yep. I completely agree. There's a big difference between knowing the semantics of a language/paradigm/system and being able to know/understand the nuances of it. It's the nuances that will get you every time...
The difference between the computing industry and the other industries you mentioned is that computing is hundreds of years younger, and thus changing orders of magnitude faster. Medicine comes the closest because of continuous research, so doctors are required to stay current with continuing education (they have to do this to maintain certification).
I have a huge problem with this. The computing industry is younger, but I don't think it's changing that much faster - a lot of "new" concepts are just recycled old concepts! Albeit wrapped slightly differently. E.g. are dumb terminals and thin clients that much different? What about, as someone else noted, worker threads and local storage? Is the concept of local storage much different than caching? And I distinctly recall being taught about threaded programming in the 1990s. The big difference now is that there is a lot more resources than before. So the current crop of applications don't really have to be developed with as much care as older code. More resources -> more resources to waste. I would consider myself an early career developer, but i've seen a lot of good and bad code from old and new developers. And I find that it's more often the newer ones that tend to rush code and leave things incomplete.
The whole idea of LAMP is that it's an easy-to-learn, easy-to-deploy stack. Any competent developer should be able to learn this, quickly. Even if you could assign a "LAMP Competence Metric" (say a 0-10 scale) to a person, a competent developer who is a 2 in LAMP will be a 9 much more quickly than an incompetent developer who is currently a 6.
When I hire coders, I like to see how quickly they can understand a system via standard UML architecture diagrams. I like to see if they can implement a basic logic task using their choice of language, and I want that implementation to be straightforward, and I want it to use the coder's chosen language's foundation libraries instead of reinventing the wheel.
I also like to get a feel for how experienced they are in working with any of the various system development processes. (Hint: "What's that?" is a bad answer. Cowboy Coders are unwelcome at my company.)
Regarding testing basic computer science concepts, I like to ask candidates to differentiate one thing from another. For example, given your list of concepts ("BNF, data normalization, OOP, MVC"), I'd ask:
I like this approach a lot. We've hired people who scored off-the-chart in standardized tests, but were completely unable to work within our relatively regimented development environment. I think the key things are work ethic (it'll be great if they could demonstrate their work ethic in multiple situations professionally or not), and the ability to learn abstract concepts and then apply them. Whatever they don't know when they start the job, they will be able to pick up. That is, of course, you require someone to be productive right away. I try not to ask "what is this?" or "define this" type of questions, but I try to ask problem solving questions to see their problem solving skills.
Why not? At least it shows that they read SOMETHING about database and organization. You don't have to agree with it, but at least there's some basis for not agreeing with it rather than repeating past mistakes.
What's the problem? Because a good programmer can find a perm position elsewhere. Unless, of course, you offer is heads and shoulders above anything else, all you're going to get from temp positions are the dregs.