понедельник, 16 марта 2009 г.
пятница, 6 марта 2009 г.
Re:Yo mama is so fat... (Score:5, Funny)
by thomasdz (178114) on Friday March 06, @08:08AM (#27090171)
понедельник, 2 марта 2009 г.
четверг, 26 февраля 2009 г.
Why I Hate Frameworks
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
Friday, September 30, 2005
----
From the discussion:
Well, good morning everyone. I wrote that little one-act play last night out of a frustrated need for catharsis (and in the midst of a bout of insomnia), and it definitely provided me with some catharsis.
But now that I'm a little more awake, I'd like to address the notion of using a framework vs. rolling your own framework.
I think it's a false dichotomy; I don't want to use any framework at all.
I know what several of you are thinking. I'd be out of my mind not to use some sort of framework. Am I honestly thinking of writing every single line of code that I'll need all on my own?
No, of course not.
What I'd really like to find are some appropriate *libraries* that I can use to provide several kinds of functionality for my project. Here's what I need:
* A library to use as a templating system for the presentation tier of my application. This API should be dirt simple.
* A library to use as a content repository (articles, essays, etc).
* A library providing a user-management API, for creating, editing, and deleting users, and assigning them different privileges.
* A library providing a threaded discussion forum API. This code should have *no* front-end gui. It should just provide an API of forum-related services that I'll need in building my webapp. I'll build my own JSP GUI on top of it.
* A library providing multi-user blogging capabilities.
Why is it so difficult to find simple libraries that provide these kinds of services?
The distinction between a library and a framework is subtle, but I think critical. A library is a collection of code that I don't have to write myself. It provides me with a set of objects and methods that I can use to build me application. If the library doesn't do quite what I want, I can make some small modifications or throw it away and use a different library.
A framework, on the other hand, always attempts to redefine the entire applilcation architecture. And, if the framework ends up not meeting my needs, I need to throw away my entire application, because everything I've written is defined in terms of the framework's methodology.
A library is something *contained* within my code.
A framework is a *container* for my application.
So, now that the working hours are in effect again, I'd like to actually *solve* my problem, rather than just complain about it. So I'm asking the JOS community whether they know of any *libraries* for building web applications. Libraries for forums, blogs, content management, user management.
No frameworks please.
BenjiSmith I'm currently in the planning stages of building a hosted Java web application (yes, it has to be Java, for a variety of reasons that I don't feel like going into right now). In the process, I'm evaluating a bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks.
And after spending dozens of hours reading through feature lists and documentation, I'm ready to gouge out my eyes.
Let's pretend I've decided to build a spice rack.
I've done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.
If I were going to build a whole house, rather than just a spice rack, I'd still need a tape measure, a saw, a level, and a hammer (among other things).
So I go to the hardware store to buy the tools, and I ask the sales clerk where I can find a hammer.
"A hammer?" he asks. "Nobody really buys hammers anymore. They're kind of old fashioned."
Surprised at this development, I ask him why.
"Well, the problem with hammers is that there are so many different kinds. Sledge hammers, claw hammers, ball-peen hammers. What if you bought one kind of hammer and then realized that you needed a different kind of hammer later? You'd have to buy a separate hammer for your next task. As it turns out, most people really want a single hammer that can handle all of the different kinds of hammering tasks you might encounter in your life."
"Hmmmmmm. Well, I suppose that sounds all right. Can you show me where to find a Universal Hammer."
"No, we don't sell those anymore. They're pretty obsolete."
"Really? I thought you just said that the Universal Hammer was the wave of the future."
"As it turns out, if you make only one kind of hammer, capable of performing all the same tasks as all those different kinds of hammers, then it isn't very good at any of them. Driving a nail with a sledgehammer isn't very effective. And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer."
"That's true. So, if nobody buys Universal Hammers anymore, and if you're no longer selling all those old-fashioned kinds of hammers, what kinds of hammers do you sell?"
"Actually, we don't sell hammers at all."
"So..."
"According to our research, what people really needed wasn't a Universal Hammer after all. It's always better to have the right kind of hammer for the job. So, we started selling hammer factories, capable of producing whatever kind of hammers you might be interested in using. All you need to do is staff the hammer factory with workers, activate the machinery, buy the raw materials, pay the utility bills, and PRESTO...you'll have *exactly* the kind of hammer you need in no time flat."
"But I don't really want to buy a hammer factory..."
"That's good. Because we don't sell them anymore."
"But I thought you just said..."
"We discovered that most people don't actually need an entire hammer factory. Some people, for example, will never need a ball-peen hammer. (Maybe they've never had ex-girlfriends. Or maybe they killed them with icepicks instead.) So there's no point in someone buying a hammer factory that can produce every kind of hammer under the sun."
"Yeah, that makes a lot of sense."
"So, instead, we started selling schematic diagrams for hammer factories, enabling our clients to build their own hammer factories, custom engineered to manufacture only the kinds of hammers that they would actually need."
"Let me guess. You don't sell those anymore."
"Nope. Sure don't. As it turns out, people don't want to build an entire factory just to manufacture a couple of hammers. Leave the factory-building up to the factory-building experts, that's what I always say!!"
"And I would agree with you there."
"Yup. So we stopped selling those schematics and started selling hammer-factory-building factories. Each hammer factory factory is built for you by the top experts in the hammer factory factory business, so you don't need to worry about all the details that go into building a factory. Yet you still get all the benefits of having your own customized hammer factory, churning out your own customized hammers, according to your own specific hammer designs."
"Well, that doesn't really..."
"I know what you're going to say!! ...and we don't sell those anymore either. For some reason, not many people were buying the hammer factory factories, so we came up with a new solution to address the problem."
"Uh huh."
"When we stepped back and looked at the global tool infrastructure, we determined that people were frustrated with having to manage and operate a hammer factory factory, as well as the hammer factory that it produced. That kind of overhead can get pretty cumbersome when you deal with the likely scenario of also operating a tape measure factory factory, a saw factory factory, and a level factory factory, not to mention a lumber manufacturing conglomerate holding company. When we really looked at the situation, we determined that that's just too complex for someone who really just wants to build a spice rack."
"Yeah, no kidding."
"So this week, we're introducing a general-purpose tool-building factory factory factory, so that all of your different tool factory factories can be produced by a single, unified factory. The factory factory factory will produce only the tool factory factories that you actually need, and each of those factory factories will produce a single factory based on your custom tool specifications. The final set of tools that emerge from this process will be the ideal tools for your particular project. You'll have *exactly* the hammer you need, and exactly the right tape measure for your task, all at the press of a button (though you may also have to deploy a few *configuration files* to make it all work according to your expectations)."
"So you don't have any hammers? None at all?"
"No. If you really want a high-quality, industrially engineered spice rack, you desperately need something more advanced than a simple hammer from a rinky-dink hardware store."
"And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?"
"Yes."
"Well…All right. I guess that's what I'll have to do. If this is the way things are done now, I guess I'd better learn how to do it."
"Good for you!!"
"This thing comes with documentation, right?"
BenjiSmith And after spending dozens of hours reading through feature lists and documentation, I'm ready to gouge out my eyes.
Let's pretend I've decided to build a spice rack.
I've done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.
If I were going to build a whole house, rather than just a spice rack, I'd still need a tape measure, a saw, a level, and a hammer (among other things).
So I go to the hardware store to buy the tools, and I ask the sales clerk where I can find a hammer.
"A hammer?" he asks. "Nobody really buys hammers anymore. They're kind of old fashioned."
Surprised at this development, I ask him why.
"Well, the problem with hammers is that there are so many different kinds. Sledge hammers, claw hammers, ball-peen hammers. What if you bought one kind of hammer and then realized that you needed a different kind of hammer later? You'd have to buy a separate hammer for your next task. As it turns out, most people really want a single hammer that can handle all of the different kinds of hammering tasks you might encounter in your life."
"Hmmmmmm. Well, I suppose that sounds all right. Can you show me where to find a Universal Hammer."
"No, we don't sell those anymore. They're pretty obsolete."
"Really? I thought you just said that the Universal Hammer was the wave of the future."
"As it turns out, if you make only one kind of hammer, capable of performing all the same tasks as all those different kinds of hammers, then it isn't very good at any of them. Driving a nail with a sledgehammer isn't very effective. And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer."
"That's true. So, if nobody buys Universal Hammers anymore, and if you're no longer selling all those old-fashioned kinds of hammers, what kinds of hammers do you sell?"
"Actually, we don't sell hammers at all."
"So..."
"According to our research, what people really needed wasn't a Universal Hammer after all. It's always better to have the right kind of hammer for the job. So, we started selling hammer factories, capable of producing whatever kind of hammers you might be interested in using. All you need to do is staff the hammer factory with workers, activate the machinery, buy the raw materials, pay the utility bills, and PRESTO...you'll have *exactly* the kind of hammer you need in no time flat."
"But I don't really want to buy a hammer factory..."
"That's good. Because we don't sell them anymore."
"But I thought you just said..."
"We discovered that most people don't actually need an entire hammer factory. Some people, for example, will never need a ball-peen hammer. (Maybe they've never had ex-girlfriends. Or maybe they killed them with icepicks instead.) So there's no point in someone buying a hammer factory that can produce every kind of hammer under the sun."
"Yeah, that makes a lot of sense."
"So, instead, we started selling schematic diagrams for hammer factories, enabling our clients to build their own hammer factories, custom engineered to manufacture only the kinds of hammers that they would actually need."
"Let me guess. You don't sell those anymore."
"Nope. Sure don't. As it turns out, people don't want to build an entire factory just to manufacture a couple of hammers. Leave the factory-building up to the factory-building experts, that's what I always say!!"
"And I would agree with you there."
"Yup. So we stopped selling those schematics and started selling hammer-factory-building factories. Each hammer factory factory is built for you by the top experts in the hammer factory factory business, so you don't need to worry about all the details that go into building a factory. Yet you still get all the benefits of having your own customized hammer factory, churning out your own customized hammers, according to your own specific hammer designs."
"Well, that doesn't really..."
"I know what you're going to say!! ...and we don't sell those anymore either. For some reason, not many people were buying the hammer factory factories, so we came up with a new solution to address the problem."
"Uh huh."
"When we stepped back and looked at the global tool infrastructure, we determined that people were frustrated with having to manage and operate a hammer factory factory, as well as the hammer factory that it produced. That kind of overhead can get pretty cumbersome when you deal with the likely scenario of also operating a tape measure factory factory, a saw factory factory, and a level factory factory, not to mention a lumber manufacturing conglomerate holding company. When we really looked at the situation, we determined that that's just too complex for someone who really just wants to build a spice rack."
"Yeah, no kidding."
"So this week, we're introducing a general-purpose tool-building factory factory factory, so that all of your different tool factory factories can be produced by a single, unified factory. The factory factory factory will produce only the tool factory factories that you actually need, and each of those factory factories will produce a single factory based on your custom tool specifications. The final set of tools that emerge from this process will be the ideal tools for your particular project. You'll have *exactly* the hammer you need, and exactly the right tape measure for your task, all at the press of a button (though you may also have to deploy a few *configuration files* to make it all work according to your expectations)."
"So you don't have any hammers? None at all?"
"No. If you really want a high-quality, industrially engineered spice rack, you desperately need something more advanced than a simple hammer from a rinky-dink hardware store."
"And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?"
"Yes."
"Well…All right. I guess that's what I'll have to do. If this is the way things are done now, I guess I'd better learn how to do it."
"Good for you!!"
"This thing comes with documentation, right?"
Friday, September 30, 2005
----
From the discussion:
Well, good morning everyone. I wrote that little one-act play last night out of a frustrated need for catharsis (and in the midst of a bout of insomnia), and it definitely provided me with some catharsis.
But now that I'm a little more awake, I'd like to address the notion of using a framework vs. rolling your own framework.
I think it's a false dichotomy; I don't want to use any framework at all.
I know what several of you are thinking. I'd be out of my mind not to use some sort of framework. Am I honestly thinking of writing every single line of code that I'll need all on my own?
No, of course not.
What I'd really like to find are some appropriate *libraries* that I can use to provide several kinds of functionality for my project. Here's what I need:
* A library to use as a templating system for the presentation tier of my application. This API should be dirt simple.
* A library to use as a content repository (articles, essays, etc).
* A library providing a user-management API, for creating, editing, and deleting users, and assigning them different privileges.
* A library providing a threaded discussion forum API. This code should have *no* front-end gui. It should just provide an API of forum-related services that I'll need in building my webapp. I'll build my own JSP GUI on top of it.
* A library providing multi-user blogging capabilities.
Why is it so difficult to find simple libraries that provide these kinds of services?
The distinction between a library and a framework is subtle, but I think critical. A library is a collection of code that I don't have to write myself. It provides me with a set of objects and methods that I can use to build me application. If the library doesn't do quite what I want, I can make some small modifications or throw it away and use a different library.
A framework, on the other hand, always attempts to redefine the entire applilcation architecture. And, if the framework ends up not meeting my needs, I need to throw away my entire application, because everything I've written is defined in terms of the framework's methodology.
A library is something *contained* within my code.
A framework is a *container* for my application.
So, now that the working hours are in effect again, I'd like to actually *solve* my problem, rather than just complain about it. So I'm asking the JOS community whether they know of any *libraries* for building web applications. Libraries for forums, blogs, content management, user management.
No frameworks please.
Friday, September 30, 2005
понедельник, 5 января 2009 г.
Why layoff?
by gillbates (106458) on Monday January 05, @11:44AM (#26331185) Homepage Journal
culling the bottom 10 or 20% of performers in order to improve the overall performance of the company.
If someone isn't doing a satisfactory job, they can be fired.
But no matter how many people you lay off, you'll always have someone in the lower 10 to 20 percentile. That's just the way statistics works.
There are a variety of reasons why culling the bottom performers seldom improves the performance of the company as a whole:
- Employees typically retain undocumented product knowledge in their heads. Someone with intimate knowledge of the codebase, who wrote the original code and debugged it, can typically turn defects around ten times faster than someone who was not involved in the original product.
- Engineers with the lowest rated performance usually get that rating because they are thorough, methodical and diligent. In other words, they keep the poor code the other engineers write from making it into the shipping version. These are not the kind of people you want to fire.
- The best performers typically sacrifice aspects of the job which aren't rated in order to achieve that rating. For example, they might write unmaintainable or difficult-to-understand code; may reinvent the wheel; might write code which is far more complicated than needed. While they meet their rated goals, their long term costs may exceed the benefit.
- Problems inevitably crop up that require novel solutions. Having a staff with a diversity of skill sets creates an environment where the best tool is used for the job, rather than having to use a single tool for every job, no matter how poorly suited, because the company laid off all employees with "unneeded" skill sets.
- There will always be employees in the lower X% no matter how many people are laid off. Typically, there is a 10 to 1 performance ratio between the best and the worst performers. Instead of simply laying off the lowest performing employees, the question should be, "Why such a large discrepancy?" The answers are often illuminating: A.) Office politics; B.) Personality conflicts; C.) Equipment/resource shortages; D.) Problems with the development process; etc... Ignoring the reasons and simply laying off employees often exacerbates the underlying problem.
I've seen management buy into the "layoff the lowest performers" myth far too often to let it go. It is almost always the harbinger of deeper, structural problems within the company, which if left unaddressed, result in the financial collapse of the company. Laying off people - even the worst performers - almost never results in a more efficient company. If you can't fire them for cause, they're more than likely adding value, even if that value isn't being measured by a performance metric. Take that away, and you take away your ability to do business.
понедельник, 20 октября 2008 г.
Firewire ports have been brutally removed from MacBook.
Yes, it is to differentiate between new MacBook and MacBook Pro.
Moreover, IMHO, this is an indication that Firewire is dead within a few years.
Reading on this issue, I found some rumors that many notebook manufacturers will soon remove firewire ports from their products.
It's only rumors now, but having Intel actively pushing USB 3.0 (with CPU-usage and bandwidth-reservation issues addressed) and the disappearing of FW-enabled products (other than audio interfaces) let me believe this becoming be a reality soon.
Bad news: USB3 is not here yet.
Funny thing is that Apple itself killed the Firewire with its licensing terms.
P.S. I'd like to thank RME for releasing ExpressCard HDSP adapter. I think Multiface II was on of my most forward-looking purchases. As of now future looks good for PCI Express.
P.P.S. Even if FW will be removed from many notebooks I'm sure they will still have ExpressCard slot, where you may insert a FW controller. I know many do this already since not every internal FW controller is good for audio work.
Moreover, IMHO, this is an indication that Firewire is dead within a few years.
Reading on this issue, I found some rumors that many notebook manufacturers will soon remove firewire ports from their products.
It's only rumors now, but having Intel actively pushing USB 3.0 (with CPU-usage and bandwidth-reservation issues addressed) and the disappearing of FW-enabled products (other than audio interfaces) let me believe this becoming be a reality soon.
Bad news: USB3 is not here yet.
Funny thing is that Apple itself killed the Firewire with its licensing terms.
P.S. I'd like to thank RME for releasing ExpressCard HDSP adapter. I think Multiface II was on of my most forward-looking purchases. As of now future looks good for PCI Express.
P.P.S. Even if FW will be removed from many notebooks I'm sure they will still have ExpressCard slot, where you may insert a FW controller. I know many do this already since not every internal FW controller is good for audio work.
Подписаться на:
Сообщения (Atom)
Yo mama is so fat...Illinois declared her a planet
Yo mama is so ugly, astronomers who look at her think they're looking at Jupiter's moon IO
Yo mama is so old, her boyfriends CARBON-date her
Yo mama is so old and fat, her stomach is actually fusing helium with neon to produce magnesium just before she turns into a neutron star!
Yo mama is so ugly, that when computer scientists look at her, they are immediately reminded of Edsger Dijkstra's letter "Go To Statement Considered Harmful" because they don't want to "Go To" her.
Ok, that last one got me severely beaten up on the playground when I was a kid, but the rest are funny and hardly trollish.