You seem to have a somewhat different definition of refactoring than the one Fowler uses in his book on refactoring, in his other writings, and in the interview referenced above.
Secondly, Fowler's book doesn't recommend refactoring for no reason. He has some specific design problems that a developer might see in a body of code they are working on. (a method too long, two classes too tightly intertwined, etc.) In his book, he describes refactoring as being the flip side of design patterns. Design patterns can be used during the design phase to create a good design. Refactoring can be used during the construction phase to become a good design.
Thirdly, the developer who didn't create a good design initially can use refactoring and come up with something better, because there are catalogs of effective refactorings The recipes that define these refactorings describe how to make these changes efficiently and safely without disturbing any more of the code than necessary.
These aspects work together like this. A developer , while coding finds that some problem is impeding their progress. For example, he discovers that every time he makes a change to one class, he discovers that he needs to make a correllary change to another class. He then decides that it fits the description of "Feature Envy", and performs the move method refactoring.
Basically, I see refactoring as a software developers equivalent of building codes. Building contractors don't need to know, or at least calculate out every time, the physics involved to make a structure solid enough to support itself and its contents. The building codes are a distilled instructions of what the physics calculations would indicate as appropriate action (with a bit of a margin of error.) Performing refactorings based on well known, tested, refactorings is using design tips of people who are much better software designers than you are.
I did get a few calls from the employer of my last job. I had been there for a while, and I really wanted to see the products that I worked on there succeed. I didn't want it all to get washed down the drain because they needed some small configuration change, and they couldn't figure it out.
After I fixed them out of their mess, I'd walk around the office with the boss and chit chat. Ask him what his future plans were for the business, make suggestions on them, point out some aspects of the current system that probably needed some work, etc. While I was at it, and while we were walking, I started laying hints for stuff around the office that I wanted. ("Oh, you had that book. I was looking all around my house for it... Hey, has anyone needed that oscilliscope since I left? etc.")
A bear cub was found in Ontario by soldiers being shipped of to WWI. Lt. Harry Colebourn named him "Winnipeg", after his hometown. The bear was loaned to the London Zoo in 1919. Cristopher Robin Milne saw the bear, and named his stuffed bear toy after it.
Canada had a series of postage stamps based on the events, and from what I can understand, Canadian stamps need to deal with Candadian events or culture.
The complaints of emacs were also on its process size just as much, if not more, than its disk space used. (hence the nickname "eight megabytes and constantly swapping")
Even there, with modern applications, the reputation is ill-deserved. On my iBook, an instance of emacs uses less memory than the Clock app that sits in the dock.
wantarray% ps auxw|sed -ne '1p' -e'/Clock.app/p' -e'/emacs/p' USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND langmead 9366 0.1 1.1 49548 3572 ?? S 0:03.83/Applications/Clock.app/Contents/MacOS/Clock -psn_0_10616833 langmead 9359 0.0 0.9 8708 3016 p2 S+ 0:00.70 emacs
Remember that Mickey Mouse is also a trademark of Disney, and that Trademarks do not have the same expiration requirements that copyrights have. Disney could use their trademarks to prevent new works from being made with Mickey Mouse or Goofy's likeness.
You can run OS X's WebDAV client over non-standard ports, so you could run something like stunnel on the local machine to SSL encrypt the data before going to the web server.
Apple solves this problem by making the dialog box translucent, so you can still see the document
through the dialog box.
Actually, Apple's solution to application modal dialogs are sheets. Essentially document modal, rather than application modal dialogs. They do obscure the current document, (so if you need to see what has changed before you can decide "Save" or "Don't Save" to "Do you want to save changes to this document before closing", you need to pick the third choice, Cancel.) You do have access the the rest of the application, though.
I'm sorry. If you are talking about NuBus cards, you are still talking about later models. The first Radius FPD was designed for the Macintosh Plus. They got around the lack of an expansion bus by having a board that clipped over the (DIP, through-hole mounted) CPU
Multiple monitor support was much earlier than that. The first multiple monitor support for the Macintosh was the Radius Full Page display, from Andy Hertzfield's first company after he left Apple.
Apple has a technote correcting Radius' suggestions on how two deal with multiple displays.
The first multiple monitor mac system built on entirely Apple produced hardware (as opposed to 3rd party add-ons.) was the Macintosh II, in 1987. That would be what Apple now calls System Software 2.0 (back when the system file and the finder had separate version numbers. What at the time I would have called System 3.3)
Computer software or systems user groups have been around for a long time. There were often strong connections between the user groups and the company the groups.
Digital, IBM, and others used to give the source of EOL's software to their user groups to distribute. Company sales reps would demonstrate new product releases or use user groups as customer feedback groups.
Corporations want that kind of support, involvement, and buy-in from their user base and it is worth a fair amount of financial support to user groups to get it.
If Apple was building hardware specifically to support interactive advertising, (which sounds unlikely to me.) they aren't using a standard banner format.
Besides, everyone knows that banner ads don't work.
I usually see the premature optimization quote attributed to C.A.R. Hoare, not Knuth. According to this web page of quotes it is often misattributed because Knuth quoted Hoare on this issue.
I agree with the rant, though. I have developed and maintained some significant sized threaded applications, and I loathe to do it again unless necessary.
I didn't think that the GPS satellites had the bandwidth to run a news feed.
One time Hayawatha Bray, the Boston Globe's technology columnist wrote an article about time syncing and he made the same mistake of saying NNTP when he meant NTP. Syncing time through Usenet has then become a running office joke. Can you imagine setting clocks through NNTP?
Start with posting a message to a newsgroup asking "what time is it?"
That will be followed by 5 contradictory answers and 3 entirely irrelevant responses. Each of those will each be responded to by 5 equally inaccurate flames.
Eventually, someone will mention in a posting that Hitler never wore a wristwatch, and the whole thing will be over.
The original IBM AT used a MC-146818A for its real time clock. Maxim/Dallas lists their DS12887A as a functionally equivalent chip. (with the addition of added non-volatile memory locations for added CMOS data. http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2682 ) The seconds are accessed from address 00h on the chip. I guess its possible for some motherboards to use different chips, but maintain the same interface by presenting 0 for seconds, but I've never come across anything like that. Reading the time from the RTC is a somewhat convoluted process, so what most systems do is to read from the RTC once, and maintain an internal counter via a timer interrupt.
What you might be thinking of was MS-DOS's FAT filesystem, which stored file timestamps as the number of even seconds since Jan 1, 1980. Or maybe the fact the RTC only reports up to seconds (so being off by.5 seconds per boot.)
I'm sorry, apparently I chose the wrong words or phrasings, since you seem to have misunderstood my message.
The eCos kernel, the kernel that RedHat acquired when it bought Cygnus, does not have a POSIX compatible, or even unix like, kernel interface. It has a kernel interface, it just looks very different than Unix. They weren't creating an incompatible kernel just to be different, they were doing it to create a kernel with features ideally suited for the development of embedded devices.
As an example, a separate thread of execution is not started with fork() or pthread_create(), but rather a thread is created with cyg_thread_create() or sta_tsk() if the ITRON API is built into the kernel. If you look at the eCos API and something with a Unix or POSIX API you will notice that few if any of the same calls exist on the two platforms.
Just to reiterate, so I'm not confusing you again. RedHat's eCos is a kernel designed for embedded systems and is not at all similar to the POSIX standard.
Now QNX as a developer of of software for the embedded market took an interesting strategy. Since there is so much software written for a POSIX style kernel, and it is an API that many people are familiar with, they created a kernel small enough for embedded devices, but gave it a POSIX API. This may make some tradeoffs in many directions, since what the program needs from the kernel and what the kernel needs to inform the code is very different for embedded devices than for a desktop or server OS.
Now to my comparison between eCos and QNX. When eCos is built with its optional EL/IX component, it starts to implement a subset of the POSIX API. So calls like read(), write(), and fcntl() are available. If you flip on the EL/IX switch, it starts getting a lot more familiar to Unix developers, which getting the product a little towards what QNX's product line does. Or at least having the same advantages.
Unfortunately, I can't quite understand how you read what I wrote originally and picked out the two sentence fragments you quoted as being a summary. If you could point out where my original post was unclear, I can try to avoid making the same mistake in the future.
Finally, to directly answer your points.
No, you are right, a kernel isn't an API, but a kernel does implement an API. eCos does implment an API, but that API (without EL/IX) is very dissimilar to POSIX.
Now for a company like QNX with a product like they have, I can perfectly well understand why they would participate in an effort like POSIX. As the committee is debating the pros and cons of particular features, they really want to be there to argue against features that could be construed as adding bloat.
Being on a committee doesn't make a vendors product more or less compatible with the standard the vendor produces.
Red Hat's embedded division wasn't selling Linux based solutions, it was selling the eCos product that came from its acquisition of Cygnus. A minimal eCos kernal can be about 4K of ROM and 1K of RAM. The kernel isn't a POSIX compliant API, (although they seem to have recently built POSIX/Linux compatibility layer on it called EL/IX which would put it in the same ballpark as QNX.) I agree with your main point though, many of the big system technologies (C++, Java, Linux) seem out of place for embedded system design.
Usually, when people take writers unfinished work after their passing, you can tell because it feels very disjointed and seems to have parts of the plot that are just left unexplained and make no sense.
I can't figure out how this would be different than any other Douglas Adams novel.
In Kernagan and Pike's The Practice of Programming they argue that programs that are written to be portable are inherently better programs. The abstractions that need to be done to make a program work across different operating systems and architectures, (and don't think of "Unix" as a single operating system. Think of it as a family of operating systems.) are abstractions that help improve program quality.
If systems seem all the same to you, then either the range of systems you have developed for are rather limited, or the complexity of the development has been rather shallow.
That doesn't mean that there is no corporate connection to Starbucks, (I don't know one way or another) but at least the Starbucks coffeehouses aren't the only retail establishments to by the tea from.
Then its a shame they didn't buy Filemaker when they had the chance. Filemaker and Powerpoint were both published by Forethought, Inc. Microsoft bought Forethought in 1987, but Filemaker was sold back to its original developers, Nashoba Systems.
Of course, the mac desktop database market was a bit crouded then. Besides Filemaker, there was MS File, Acius' 4D, Ashton-Tate's dBase Mac, Omni III, Borland's Reflex. And that was also right about the time that Apple was about the time Apple was distributing Hypercard with every mac, pretty much destroying the Mac database market (Can you believe they tried calling Hypercard "System Software" in order to distribute it with the OS?)
Slashdot Mirror
You seem to have a somewhat different definition of refactoring than the one Fowler uses in his book on refactoring, in his other writings, and in the interview referenced above.
First of all, adding OLE or CORBA would not be Refactoring. Fowler described it like this:Refactoring is making changes to a body of code in order to improve its internal structure, without changing its external behavior.
Secondly, Fowler's book doesn't recommend refactoring for no reason. He has some specific design problems that a developer might see in a body of code they are working on. (a method too long, two classes too tightly intertwined, etc.) In his book, he describes refactoring as being the flip side of design patterns. Design patterns can be used during the design phase to create a good design. Refactoring can be used during the construction phase to become a good design.
Thirdly, the developer who didn't create a good design initially can use refactoring and come up with something better, because there are catalogs of effective refactorings The recipes that define these refactorings describe how to make these changes efficiently and safely without disturbing any more of the code than necessary.
These aspects work together like this. A developer , while coding finds that some problem is impeding their progress. For example, he discovers that every time he makes a change to one class, he discovers that he needs to make a correllary change to another class. He then decides that it fits the description of "Feature Envy", and performs the move method refactoring.
Basically, I see refactoring as a software developers equivalent of building codes. Building contractors don't need to know, or at least calculate out every time, the physics involved to make a structure solid enough to support itself and its contents. The building codes are a distilled instructions of what the physics calculations would indicate as appropriate action (with a bit of a margin of error.) Performing refactorings based on well known, tested, refactorings is using design tips of people who are much better software designers than you are.
I did get a few calls from the employer of my last job. I had been there for a while, and I really wanted to see the products that I worked on there succeed. I didn't want it all to get washed down the drain because they needed some small configuration change, and they couldn't figure it out.
After I fixed them out of their mess, I'd walk around the office with the boss and chit chat. Ask him what his future plans were for the business, make suggestions on them, point out some aspects of the current system that probably needed some work, etc. While I was at it, and while we were walking, I started laying hints for stuff around the office that I wanted. ("Oh, you had that book. I was looking all around my house for it... Hey, has anyone needed that oscilliscope since I left? etc.")
A bear cub was found in Ontario by soldiers being shipped of to WWI. Lt. Harry Colebourn named him "Winnipeg", after his hometown. The bear was loaned to the London Zoo in 1919. Cristopher Robin Milne saw the bear, and named his stuffed bear toy after it. Canada had a series of postage stamps based on the events, and from what I can understand, Canadian stamps need to deal with Candadian events or culture.
The complaints of emacs were also on its process size just as much, if not more, than its disk space used. (hence the nickname "eight megabytes and constantly swapping")
Even there, with modern applications, the reputation is ill-deserved. On my iBook, an instance of emacs uses less memory than the Clock app that sits in the dock.
Remember that Mickey Mouse is also a trademark of Disney, and that Trademarks do not have the same expiration requirements that copyrights have. Disney could use their trademarks to prevent new works from being made with Mickey Mouse or Goofy's likeness.
You can run OS X's WebDAV client over non-standard ports, so you could run something like stunnel on the local machine to SSL encrypt the data before going to the web server.
I'm sorry. If you are talking about NuBus cards, you are still talking about later models. The first Radius FPD was designed for the Macintosh Plus. They got around the lack of an expansion bus by having a board that clipped over the (DIP, through-hole mounted) CPU
Apple has a technote correcting Radius' suggestions on how two deal with multiple displays.
The first multiple monitor mac system built on entirely Apple produced hardware (as opposed to 3rd party add-ons.) was the Macintosh II, in 1987. That would be what Apple now calls System Software 2.0 (back when the system file and the finder had separate version numbers. What at the time I would have called System 3.3)
Computer software or systems user groups have been around for a long time. There were often strong connections between the user groups and the company the groups.
Digital, IBM, and others used to give the source of EOL's software to their user groups to distribute. Company sales reps would demonstrate new product releases or use user groups as customer feedback groups.
Corporations want that kind of support, involvement, and buy-in from their user base and it is worth a fair amount of financial support to user groups to get it.
The X Window system specifies mechanisms, not policy.
Not every advertising form works on increasing the annoyance. Some advertising attempts to be pervasive but not annoying.
Advertisements from Search Engine companies look a little different other companies. They look more like the bottom half of this page.
If Apple was building hardware specifically to support interactive advertising, (which sounds unlikely to me.) they aren't using a standard banner format.
Besides, everyone knows that banner ads don't work.
I think what you want is:
in the SYSTEM.INI file.I agree with the rant, though. I have developed and maintained some significant sized threaded applications, and I loathe to do it again unless necessary.
I didn't think that the GPS satellites had the bandwidth to run a news feed.
One time Hayawatha Bray, the Boston Globe's technology columnist wrote an article about time syncing and he made the same mistake of saying NNTP when he meant NTP. Syncing time through Usenet has then become a running office joke. Can you imagine setting clocks through NNTP?
Start with posting a message to a newsgroup asking "what time is it?"
That will be followed by 5 contradictory answers and 3 entirely irrelevant responses. Each of those will each be responded to by 5 equally inaccurate flames.
Eventually, someone will mention in a posting that Hitler never wore a wristwatch, and the whole thing will be over.
The original IBM AT used a MC-146818A for its real time clock. Maxim/Dallas lists their DS12887A as a functionally equivalent chip. (with the addition of added non-volatile memory locations for added CMOS data. http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2682 ) The seconds are accessed from address 00h on the chip. I guess its possible for some motherboards to use different chips, but maintain the same interface by presenting 0 for seconds, but I've never come across anything like that. Reading the time from the RTC is a somewhat convoluted process, so what most systems do is to read from the RTC once, and maintain an internal counter via a timer interrupt.
.5 seconds per boot.)
What you might be thinking of was MS-DOS's FAT filesystem, which stored file timestamps as the number of even seconds since Jan 1, 1980. Or maybe the fact the RTC only reports up to seconds (so being off by
The eCos kernel, the kernel that RedHat acquired when it bought Cygnus, does not have a POSIX compatible, or even unix like, kernel interface. It has a kernel interface, it just looks very different than Unix. They weren't creating an incompatible kernel just to be different, they were doing it to create a kernel with features ideally suited for the development of embedded devices.
As an example, a separate thread of execution is not started with fork() or pthread_create(), but rather a thread is created with cyg_thread_create() or sta_tsk() if the ITRON API is built into the kernel. If you look at the eCos API and something with a Unix or POSIX API you will notice that few if any of the same calls exist on the two platforms. Just to reiterate, so I'm not confusing you again. RedHat's eCos is a kernel designed for embedded systems and is not at all similar to the POSIX standard.
Now QNX as a developer of of software for the embedded market took an interesting strategy. Since there is so much software written for a POSIX style kernel, and it is an API that many people are familiar with, they created a kernel small enough for embedded devices, but gave it a POSIX API. This may make some tradeoffs in many directions, since what the program needs from the kernel and what the kernel needs to inform the code is very different for embedded devices than for a desktop or server OS.
Now to my comparison between eCos and QNX. When eCos is built with its optional EL/IX component, it starts to implement a subset of the POSIX API. So calls like read(), write(), and fcntl() are available. If you flip on the EL/IX switch, it starts getting a lot more familiar to Unix developers, which getting the product a little towards what QNX's product line does. Or at least having the same advantages.
Unfortunately, I can't quite understand how you read what I wrote originally and picked out the two sentence fragments you quoted as being a summary. If you could point out where my original post was unclear, I can try to avoid making the same mistake in the future.
Finally, to directly answer your points.
Red Hat's embedded division wasn't selling Linux based solutions, it was selling the eCos product that came from its acquisition of Cygnus. A minimal eCos kernal can be about 4K of ROM and 1K of RAM. The kernel isn't a POSIX compliant API, (although they seem to have recently built POSIX/Linux compatibility layer on it called EL/IX which would put it in the same ballpark as QNX.) I agree with your main point though, many of the big system technologies (C++, Java, Linux) seem out of place for embedded system design.
Usually, when people take writers unfinished work after their passing, you can tell because it feels very disjointed and seems to have parts of the plot that are just left unexplained and make no sense.
I can't figure out how this would be different than any other Douglas Adams novel.
Each one of them could be a DHCP relay agent as well, and keep the DHCP server on the common hotel network.
If systems seem all the same to you, then either the range of systems you have developed for are rather limited, or the complexity of the development has been rather shallow.
That doesn't mean that there is no corporate connection to Starbucks, (I don't know one way or another) but at least the Starbucks coffeehouses aren't the only retail establishments to by the tea from.
Then its a shame they didn't buy Filemaker when they had the chance. Filemaker and Powerpoint were both published by Forethought, Inc. Microsoft bought Forethought in 1987, but Filemaker was sold back to its original developers, Nashoba Systems.
Of course, the mac desktop database market was a bit crouded then. Besides Filemaker, there was MS File, Acius' 4D, Ashton-Tate's dBase Mac, Omni III, Borland's Reflex. And that was also right about the time that Apple was about the time Apple was distributing Hypercard with every mac, pretty much destroying the Mac database market (Can you believe they tried calling Hypercard "System Software" in order to distribute it with the OS?)