At first my web stack was: 10% JavaScript, 60% PHP, 10% Apache, and 20% PostgreSQL. Now it's more like: 30% JavaScript, 10% PHP, 20% Apache, and 40% PostgreSQL, as I learned more about those other layers.
I try to limit the PHP to just a thin connection layer to the database: $db = new PDO; $q = 'select a fairly refined query that does all the calculation and filtering'; $q = $db->prepare($q); $q->execute($v);
and as a templating language, using short tags and the alternate syntax: <table> <? foreach ($records as $r): ?>
<tr>
<td><?= h($r['id']) ?></td>
<td><?= h($r['name']) ?></td>
<td><?= h($r['note']) ?></td>
</tr> <? endforeach ?> </table>
I agree. Something I read 10 years ago really resonated with me, and it refutes this whole idea. From The New Methodology (2005):
Separation of Design and Construction
"The usual inspiration for methodologies is engineering disciplines such as civil or mechanical engineering. . . . Many design decisions, such as how to deal with the load on a bridge, are made as the drawings are produced. The drawings are then handed over to a different group, often a different company, to be built. . . . This allows the construction to be less skilled intellectually, although they are often very skilled manually. . . . So what we see here are two fundamentally different activities. Design which is difficult to predict and requires expensive and creative people, and construction which is easier to predict.
". . . But here lies the crucial question. Can you get a design that is capable of turning the coding into a predictable construction activity? . . . The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing. . . . This raises an important question about the nature of design in software compared to its role in other branches of engineering.
"These kinds of questions led Jack Reeves to suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.
I've never heard it said ess yoo. I tried to google it but only found threads about sudo. They were split between soodoo and pseudo. No one was arguing for ess-yoo doo or ess-yoo dough. Come to think of it, there are several words like this:
This is another case where the 80-20 rule comes into play. Almost everyone could switch to LibreOffice, but there are edge cases where Microsoft works better.
I uninstalled Microsoft Office and installed LibreOffice on my work laptop about a year or so ago. I'm a web programmer, so I use it only once every couple of weeks, to read and sometimes edit Word and Excel files from coworkers. So far so good. I even made a user guide with Write, including drawings made in Draw. I published it to PDF, so compatibility doesn't come up. Still, I liked using OpenOffice more than Microsoft Office, even ten years ago.
I could not agree more, but with one slight modification:
I do not think that "quietly" needs to fit. I think that RMS (who should be on your list), Linus and others who are among the pantheon of great programmers are not necessarily quiet. In fact, I don't want them to be. I want them to proclaim their lessons and techniques. I want to hear about how they go about their jobs. I want to learn from them.
That said, I completely agree with what I think was your sentiment in saying, "quietly". Perhaps humble or thoughtful is a better way to put it.
"Rock star programmer" just makes me think diva, someone who is hard to deal with, because they think highly of themselves. Generally these people are not awful. They are either average or good, but they normally not good enough to put up with their pride. "Rock star" also makes me think of programmers who subscribe to the latest trends.
Would you call these people "rock stars": Dennis Ritchie, Brian Kernighan, Rob Pike, Larry Wall, Linus Tovalds? The good programmers don't make me think rock star. They make me think expert, master, craftsman, or journeyman. In other words, someone who works quietly, turning out software that quietly does the job reliably.
Part if it may be a emotional distance from dealing for 35 years with customers. Or from being a manager.
I can tell that I myself have got jaded after being alive for 35 years. I have had to deal with only dozens of customers. And I have been the boss of only one other person. And I have consciously tried not to get jaded, to remain open and welcoming. And yet I can see that I'm different than I was 10 or 20 years ago.
We also hired patent lawyers and consultants familiar with this technology area. We created a new codec development process which would allow us to work through the long list of patents in this space, and continually evolve our codec to work around or avoid those patents.
I'm so glad that patents are doing their intended purpose of encouraging progress. Nothing fosters progress like taking a long, circuitous route instead of the straight and patently obvious one.
Slicing PSDs is crude, antiquated (even though most shops still do it), and reinforces the fallacy that web design begins in Photoshop.
Modernize your curriculum to teach progressive enhancement of wireframe layouts in the browser. At some point you teach about creating the individual image assets for what they are (backgrounds, icons, etc) rather than treating a PSD as a giant slab of source material. For this, you can use GIMP, Inkscape, or anything else Free.
You are perpetuating Adobe's dominance by furthering a bad workflow that benefits them. Your course isn't about Photoshop, that shouldn't be the keystone of it.
Slicing PSDs is the equivalent of beginning a construction project from a child's crayon drawing of the not-yet-existing building.
I agree, and this is coming from someone who came into web programming from graphic design. I first learned Photoshop. I soon abandoned it once I got a job in web programming.
It is better to write HTML in a text editor. Then add CSS. If you must, add images from Photoshop or whatever. But I hardly ever even do that anymore. Granted, it's harder to learn to code raw HTML in a text editor. But I would rather you start with Dreamweaver or some WYSIWYG editor than making a web page in Photoshop, slicing it up, and converting it into a web page.
Photoshop is pixel-based. The web is elastic. Photoshop encourages you to make image-heavy, user-unfriendly, obnoxious brochures --- instead of lean, useful, get-out-of-the-way web pages.
I don't always use the Caps Lock key, but when I do, it's usually on accident.
On my computer at work, I got so fed up that I pried off the Caps Lock key. I also pried off the Insert key, a key I never press on purpose. I was much happier.
I think the question is whether everyone should be writing software AND then attempting to sell it to others via the app store. The answer to that, IMHO is no, as making software for others requires a level of professionalism and quality not everyone can reach.
But it would be nice if we could somehow rewind back to the 80s in which every computer came with a simple programming language so that if I wanted to throw together some code to do a simple task for my own benefit, I could do so quickly and easily.
(Note to Apple: Bring back HyperCard, please!)
In my limited experience, the simple tool that someone makes to scratch their own itch is often better than the bloated, passionless produkt from some corporate labyrinth.
Without reading anything besides your summary, it sounds like you're on the right track. "Minimalism" and "simplicity," judiciously applied, usually leads to a good result. As Albert Einstein said, "Everything should be as simple as possible, but not simpler."
In 2002 they developed a 350 GHz silicon-germanium transistor. In 2006 they developed a silicon-germanium processor that reached 350 GHz at room temperature and 500 GHz when supercooled with liquid helium.
Complete: It covers all of the main facts. There was no big question left in my mind after reading it. It's so complete that many will not go on to the article itself. (Not that they would anyway. This is Slashdot.) But that's what headlines and leads are supposed to do. They are supposed to tell the whole story, from beginning to end --- just not with every last detail. If you want all the last details, you read the rest of the article.
Approachable: It defines all but the most common acroynms. For one it even goes further than just spelling out the acronym and also gives a nice little picture: ". . . 3D V-NAND technology, which stacks 32 layers of NAND atop one another in a microscopic skyscraper."
Well-built: The English is good. Although technical, it uses plain English where it can instead of buzzwords. The sentences are not too long or tangled with several interdependent clauses. They have a good rhythm. You hear the words in your head even when reading silently, so sonic things still matter, like rhythm, alliteration, and rhyme (That doesn't mean you should rhyme all the time).
As a former professional technical writer, I am always on the look-out for good explanatory writing. I wanted to call it out here, especially since often we just complain when the summary's bad. When something's good, we're often silent. I suppose that's partly because when things are working, like the utility company, they don't attract attention and we just take them for granted. But writing like this is no accident.
First, this survey was not mainly about grandmothers. They had "ages ranging from their 30s to well into their 90s," and "a vast number of responses involved highly skilled, technologically-savvy individuals -- often engineers themselves."
The overwhelming complaints were of:
- "low-contrast interfaces and fonts, gray fonts on gray backgrounds"
- "Hidden menus. Obscure interface elements (e.g., tiny upside-down arrows). Interface and menu elements that only appear if you've moused over a particular location on the display. Interface elements that are so small or ephemeral that they can be a challenge to click even if you still have the motor skills of youth."
- "the sudden change of an icon from a wrench to a gear, or a change in a commonly used icon's position"
Forget programmers. We need to encourage kids to go into battery technology (joking). Although batteries have gotten better, their pace seems stubbornly slow when you consider that we've tried making electric cars since the nineteenth century:
1. Price. The reason for the high price of electric cars has got to be the batteries. An electric car can throw out many of the parts a gas car has, including the transmission. Yet they still cost more. It's got to be the batteries.
2. Range. Electric cars need much more range than gas cars to really catch on, because they have fewer places to recharge. When an electric car has a range of 500 miles and sells for 25% less than the gas-powered equivalent, then it will catch on.
"I'm gonna see it! I want it to be as beautiful as possible, even if it's inside the box. A great carpenter isn't going to use lousy wood for the back of a cabinet, even though nobody's going to see it." This is Steve Jobs pushing the Macintosh team to redesign the circuit board because some of the spacing was ugly.
"My passion has been to build an enduring company where people were motivated to make great products . . . the products, not the profits, were the motivation. Sculley flipped these priorities to where the goal was to make money. It's a subtle difference, but it ends up meaning everything."
Most of us get sucked into management, like a poor Millenium Falcon into the Death Star's tractor beam. More useful would be an article about how to refuse such offers, keep getting raises and offers for programming jobs as we grow older, and so on.
You will get promoted to management, at least to team lead, just by not sucking.
And in my own experience at least, in the healthcare industry, there are plenty of gray-haired technical people. And when I was helping to hire another programmer, I was hoping for a graybeard, not because of agism, but experiencism.
This article is less critical of jQuery than the summary led me to believe. It just warns you against two things: (1) a long procedure of code for the ready argument, "The Big Main Method Problem," and (2) DOM-centric code. But neither of these are problems, and neither of them are caused or even encouraged by jQuery.
After the click-baitish FUD, the summary goes on, saying you might as well use it anyway:
The phrase "probably essential" is a weird combination of a weak and a strong word, and may be a sign of a writer who is half asleep.
but what are the most important elements to learn in order to become adept-enough at it? Chaining commands, understanding when the document is finished loading (and how to write code that safely accesses elements only after said loading), and learning CSS selectors are all key. The harder part is picking up jQuery's quirks and tricks, of which there are many... but is it worth studying to the point where you know every possible eccentricity?
Who cares? The jQuery reference is easy to browse for whatever you need right now, and there's little need to understand one part of jQuery to use another.
While my friends listened to "Smells Like Teen Spirit," I listened to the soundtrack to Glory.
Re:The problem is that landfills are too cheap
on
Recycling Is Dying
·
· Score: 4, Insightful
I'd sort, but I'm not going to sort AND pay extra money.
Yep. I was pretty diligent about recycling right up till the local government decided that they needed to charge extra for recycling. When they required me to do extra work AND pay extra money for the service, I stopped using the service....
Is it the government that requires you to do extra work and pay extra money, or is it just life?
Recycling takes a certain amount of work. The government may be trying to split it with you. If they did all of the work, maybe the would have to charge even more.
I may be wrong, and someone will certainly say something like that the government is just being greedy or wasteful. But if it were me, I would either investigate it to know for sure or just go with it.
Slashdot Mirror
At first my web stack was: 10% JavaScript, 60% PHP, 10% Apache, and 20% PostgreSQL.
Now it's more like: 30% JavaScript, 10% PHP, 20% Apache, and 40% PostgreSQL, as I learned more about those other layers.
I try to limit the PHP to just a thin connection layer to the database:
$db = new PDO;
$q = 'select a fairly refined query that does all the calculation and filtering';
$q = $db->prepare($q);
$q->execute($v);
and as a templating language, using short tags and the alternate syntax:
<table>
<? foreach ($records as $r): ?>
<tr>
<td><?= h($r['id']) ?></td>
<td><?= h($r['name']) ?></td>
<td><?= h($r['note']) ?></td>
</tr>
<? endforeach ?>
</table>
I agree. Something I read 10 years ago really resonated with me, and it refutes this whole idea. From The New Methodology (2005):
Separation of Design and Construction
"The usual inspiration for methodologies is engineering disciplines such as civil or mechanical engineering. . . . Many design decisions, such as how to deal with the load on a bridge, are made as the drawings are produced. The drawings are then handed over to a different group, often a different company, to be built. . . . This allows the construction to be less skilled intellectually, although they are often very skilled manually. . . . So what we see here are two fundamentally different activities. Design which is difficult to predict and requires expensive and creative people, and construction which is easier to predict.
". . . But here lies the crucial question. Can you get a design that is capable of turning the coding into a predictable construction activity? . . . The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing. . . . This raises an important question about the nature of design in software compared to its role in other branches of engineering.
"These kinds of questions led Jack Reeves to suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.
a) "an su." Write it like you'd say it
I've never heard it said ess yoo. I tried to google it but only found threads about sudo. They were split between soodoo and pseudo. No one was arguing for ess-yoo doo or ess-yoo dough. Come to think of it, there are several words like this:
Linux: lin nux, lie nux, lee nux /etc: et see, ee tee see, etcetera
SQL: sequel, ess cue el
Even punctuation has its variants.
More fun reading.
How long until systemd absorbs emacs?
Hilarious :)
You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away.
-- Antoine de Saint-Exupery
Love that quote.
This is another case where the 80-20 rule comes into play. Almost everyone could switch to LibreOffice, but there are edge cases where Microsoft works better.
I uninstalled Microsoft Office and installed LibreOffice on my work laptop about a year or so ago. I'm a web programmer, so I use it only once every couple of weeks, to read and sometimes edit Word and Excel files from coworkers. So far so good. I even made a user guide with Write, including drawings made in Draw. I published it to PDF, so compatibility doesn't come up. Still, I liked using OpenOffice more than Microsoft Office, even ten years ago.
I could not agree more, but with one slight modification:
I do not think that "quietly" needs to fit. I think that RMS (who should be on your list), Linus and others who are among the pantheon of great programmers are not necessarily quiet. In fact, I don't want them to be. I want them to proclaim their lessons and techniques. I want to hear about how they go about their jobs. I want to learn from them.
That said, I completely agree with what I think was your sentiment in saying, "quietly". Perhaps humble or thoughtful is a better way to put it.
Yes, I accept your patch for my comment ;)
"Rock star programmer" just makes me think diva, someone who is hard to deal with, because they think highly of themselves. Generally these people are not awful. They are either average or good, but they normally not good enough to put up with their pride. "Rock star" also makes me think of programmers who subscribe to the latest trends.
Would you call these people "rock stars": Dennis Ritchie, Brian Kernighan, Rob Pike, Larry Wall, Linus Tovalds? The good programmers don't make me think rock star. They make me think expert, master, craftsman, or journeyman. In other words, someone who works quietly, turning out software that quietly does the job reliably.
Well no, it's called slashdot (/.) but you do know where that comes from right?
Well I do, but you might not - it was intended as a joke to make the site name hard to read out, i.e. h-t-t-p-colon-slash-slash-slashdot-dot-org.
I think it would have been cleverer to call it DotSlash (./) with the slogan "You are here."
Part if it may be a emotional distance from dealing for 35 years with customers. Or from being a manager.
I can tell that I myself have got jaded after being alive for 35 years. I have had to deal with only dozens of customers. And I have been the boss of only one other person. And I have consciously tried not to get jaded, to remain open and welcoming. And yet I can see that I'm different than I was 10 or 20 years ago.
From the summary:
A new report from Adobe and one of several startups helping publishers fight ad blocking
Well, now I really don't like Adobe anymore.
From the summary:
We also hired patent lawyers and consultants familiar with this technology area. We created a new codec development process which would allow us to work through the long list of patents in this space, and continually evolve our codec to work around or avoid those patents.
I'm so glad that patents are doing their intended purpose of encouraging progress. Nothing fosters progress like taking a long, circuitous route instead of the straight and patently obvious one.
Slicing PSDs is crude, antiquated (even though most shops still do it), and reinforces the fallacy that web design begins in Photoshop.
Modernize your curriculum to teach progressive enhancement of wireframe layouts in the browser. At some point you teach about creating the individual image assets for what they are (backgrounds, icons, etc) rather than treating a PSD as a giant slab of source material. For this, you can use GIMP, Inkscape, or anything else Free.
You are perpetuating Adobe's dominance by furthering a bad workflow that benefits them. Your course isn't about Photoshop, that shouldn't be the keystone of it.
Slicing PSDs is the equivalent of beginning a construction project from a child's crayon drawing of the not-yet-existing building.
I agree, and this is coming from someone who came into web programming from graphic design. I first learned Photoshop. I soon abandoned it once I got a job in web programming.
It is better to write HTML in a text editor. Then add CSS. If you must, add images from Photoshop or whatever. But I hardly ever even do that anymore. Granted, it's harder to learn to code raw HTML in a text editor. But I would rather you start with Dreamweaver or some WYSIWYG editor than making a web page in Photoshop, slicing it up, and converting it into a web page.
Photoshop is pixel-based. The web is elastic. Photoshop encourages you to make image-heavy, user-unfriendly, obnoxious brochures --- instead of lean, useful, get-out-of-the-way web pages.
I don't always use the Caps Lock key, but when I do, it's usually on accident.
On my computer at work, I got so fed up that I pried off the Caps Lock key. I also pried off the Insert key, a key I never press on purpose. I was much happier.
I think the question is whether everyone should be writing software AND then attempting to sell it to others via the app store. The answer to that, IMHO is no, as making software for others requires a level of professionalism and quality not everyone can reach.
But it would be nice if we could somehow rewind back to the 80s in which every computer came with a simple programming language so that if I wanted to throw together some code to do a simple task for my own benefit, I could do so quickly and easily.
(Note to Apple: Bring back HyperCard, please!)
In my limited experience, the simple tool that someone makes to scratch their own itch is often better than the bloated, passionless produkt from some corporate labyrinth.
Without reading anything besides your summary, it sounds like you're on the right track. "Minimalism" and "simplicity," judiciously applied, usually leads to a good result. As Albert Einstein said, "Everything should be as simple as possible, but not simpler."
In 2006 they developed a 350GHz room temperature capable silicon gallium CPU. Where is that?
No they didn't. They developed a 350 GHz room temperature transistor.
According to this article it was a CPU:
http://www.techspot.com/news/2...
Maybe the article is wrong?
In 2002 they developed a 350 GHz silicon-germanium transistor.
In 2006 they developed a silicon-germanium processor that reached 350 GHz at room temperature and 500 GHz when supercooled with liquid helium.
This summary is well written. It is:
As a former professional technical writer, I am always on the look-out for good explanatory writing. I wanted to call it out here, especially since often we just complain when the summary's bad. When something's good, we're often silent. I suppose that's partly because when things are working, like the utility company, they don't attract attention and we just take them for granted. But writing like this is no accident.
First, this survey was not mainly about grandmothers. They had "ages ranging from their 30s to well into their 90s," and "a vast number of responses involved highly skilled, technologically-savvy individuals -- often engineers themselves."
The overwhelming complaints were of:
- "low-contrast interfaces and fonts, gray fonts on gray backgrounds"
- "Hidden menus. Obscure interface elements (e.g., tiny upside-down arrows). Interface and menu elements that only appear if you've moused over a particular location on the display. Interface elements that are so small or ephemeral that they can be a challenge to click even if you still have the motor skills of youth."
- "the sudden change of an icon from a wrench to a gear, or a change in a commonly used icon's position"
Forget programmers. We need to encourage kids to go into battery technology (joking). Although batteries have gotten better, their pace seems stubbornly slow when you consider that we've tried making electric cars since the nineteenth century:
1. Price. The reason for the high price of electric cars has got to be the batteries. An electric car can throw out many of the parts a gas car has, including the transmission. Yet they still cost more. It's got to be the batteries.
2. Range. Electric cars need much more range than gas cars to really catch on, because they have fewer places to recharge. When an electric car has a range of 500 miles and sells for 25% less than the gas-powered equivalent, then it will catch on.
"I'm gonna see it! I want it to be as beautiful as possible, even if it's inside the box. A great carpenter isn't going to use lousy wood for the back of a cabinet, even though nobody's going to see it." This is Steve Jobs pushing the Macintosh team to redesign the circuit board because some of the spacing was ugly.
Steve Jobs also pushed them to make it boot as fast as possible, rejected computer fans because of noise, and said a multibutton mouse would be inelegant. He went to great pains to make the Apple Store out of glass. Even his slides were Zen.
He was a complex character. He certainly wasn't your typical businessman:
"My passion has been to build an enduring company where people were motivated to make great products . . . the products, not the profits, were the motivation. Sculley flipped these priorities to where the goal was to make money. It's a subtle difference, but it ends up meaning everything."
Most of us get sucked into management, like a poor Millenium Falcon into the Death Star's tractor beam. More useful would be an article about how to refuse such offers, keep getting raises and offers for programming jobs as we grow older, and so on.
You will get promoted to management, at least to team lead, just by not sucking.
And in my own experience at least, in the healthcare industry, there are plenty of gray-haired technical people. And when I was helping to hire another programmer, I was hoping for a graybeard, not because of agism, but experiencism.
jQuery isn't without its controversies
Huh?
and some developers distrust its use in larger projects because (some say) it ultimately leads to breakage-prone code that's harder to maintain.
This article is less critical of jQuery than the summary led me to believe. It just warns you against two things: (1) a long procedure of code for the ready argument, "The Big Main Method Problem," and (2) DOM-centric code. But neither of these are problems, and neither of them are caused or even encouraged by jQuery.
After the click-baitish FUD, the summary goes on, saying you might as well use it anyway:
But given its prevalence, jQuery is probably essential to know
The phrase "probably essential" is a weird combination of a weak and a strong word, and may be a sign of a writer who is half asleep.
but what are the most important elements to learn in order to become adept-enough at it? Chaining commands, understanding when the document is finished loading (and how to write code that safely accesses elements only after said loading), and learning CSS selectors are all key. The harder part is picking up jQuery's quirks and tricks, of which there are many... but is it worth studying to the point where you know every possible eccentricity?
Who cares? The jQuery reference is easy to browse for whatever you need right now, and there's little need to understand one part of jQuery to use another.
While my friends listened to "Smells Like Teen Spirit," I listened to the soundtrack to Glory.
Yep. I was pretty diligent about recycling right up till the local government decided that they needed to charge extra for recycling. When they required me to do extra work AND pay extra money for the service, I stopped using the service....
Is it the government that requires you to do extra work and pay extra money, or is it just life?
Recycling takes a certain amount of work. The government may be trying to split it with you. If they did all of the work, maybe the would have to charge even more.
I may be wrong, and someone will certainly say something like that the government is just being greedy or wasteful. But if it were me, I would either investigate it to know for sure or just go with it.