There shouldn't be mountains of C# to wade through to get data. If so, the implementation is off. The concept, however, I a big fan of. Even when the impedance is high.
Which gets down to the root problem: The developers wrote a mountain of useless C#. ORM really wasn't an appropriate tool for the project, because it just didn't need all of the things that you use ORM for. All that was needed was a simple layer to map ADO results to objects, or even better, a document database.
Another thing to consider is OODBs. I'm going to be looking at db4o pretty soon because this situation is just intolerable. I had a call with Objectivity, but they wanted in the neighborhood of $80K for a 100 client installation on a 4 processor machine with 3 developer licenses, and that's way beyond our budget. Would have probably been perfect for our situation though, due to the way they wrote the code.
Be careful with DB4o. I played with in in 2005-2006, and its object-loading scheme was somewhat confusing. You need to "know" that your in-memory objects can be incomplete, which means that you continually need to activate them.
MongoDB, with their C# drivers, is a very similar "sales pitch" to Objectivity. Both the MongoDB and Objectivity drivers let you work with real C# objects. The reason why I like MongoDB, (in addition to its cost,) is that you can have an entire graph of objects that are persisted to the database as a document, and then you can query the database to get back these objects.
Frankly, the reason why I recommend "document" databases instead of object oriented ones is that, in situations like MongoDB, they pretty much are an object-oriented database, except the "document" aspect means that you don't get into the incomplete object graph issue that db4o put me in.
Parent sounds a little like they were in over their head. Was the problem NHibernate (the implementation) or the ORM (the concept)?
Both.
The problem was rooted in the fact that the engineers who started and lead the project had no clue how to program with a relational database, and treated NHibernate as a magic persistance layer. They would just quote the mantra of "Like Inversion Of Control, Test Driven Design, Policy Injection, Design By Contract" and then totally misunderstand how to act on the concepts.
IE, they would do things like foreach over an entire table instead of "select where parentid=123". They would also suck an entire database into RAM, change 1-2 fields, instead of writing a simple update statement. When it was appropriate to just write a %$@%#$ query, they would write tons of C# that would put a huge load on the database. They would also do things like load tons of objects and pass them around, when all you need are IDs.
So yes, it was a mis-applied tool. But, the issue was complicated that those of us who knew how to use a database just found that NHibernate would get in our way when 100s of lines of C# would be better replaced by a simple stored procedure. IE, NHibernate never added any value, except for simplifying basic CRUD.
In contrast, the most successful database work that I've done had a database programming expert on the team. The vast majority of data manipulation was done in raw SQL with stored procedures, and then we had a simple ORM that helped populate query results and generate wrappers to call stored procedures. There wasn't any framework to get in the way.
I had the misfortune of developing with NHibernate. The root of the problem was that the engineers who started the project didn't know anything about database programming and just used NHibernate as a magic persistance layer. (These guys would write foreach loops that would suck most of the database into RAM.) Ultimately, as I learned the tool, I found that it just makes data access more complicated then it needs to be. In order to use it right, you have to know the underlying database programming concepts, which are simpler and easier to learn then the NHibernate library.
To make matters worse, when I used NHibernate, there was a bug in runtime code generation, which was very hard to track down and impossible to fix.
My opinion: Stick with a simple ADO -> Object mapper and write queries as-needed. If you use NHibernate, stick with the basic CRUD features. Don't rely on a more complicated library to handle things like transactions, lazy-loading, and relationship mapping. Be very careful introducing relationships into the business objects, especially automatically-populated ones. And, whatever you do, if you end up working in a project where the senior engineers and/or people who started the project treat NHibernate as a "magic persistance layer," RUN!!!
Oh, and if you work on a project that wants a "magic persistance layer," because the engineers don't get databases, investigate document databases like MongoDB, Couch, ect. The document model maps a lot better to the object-oriented way of doing things, thus it's a lot harder for programmers who don't get databases to screw them up.
They never make any public info, but it's crazy what kind of logic blocks they find on silicon.
Sometimes scraping can tell simpler things, like an accurate estimate about how much profit a company is making on a chip, and thus how much money the company will have to invest in its next generation of chips.
No, that's understanding the design of the CLR. It allows APIs that are platform specific and APIs that are platform neutral. Assuming that you build against Microsoft-specific or Windows-specific APIs, then you're not going to run well, or at all, on Linux.
When I said GUI, I meant WinForms. I should have been more specific. A WinForms C# App isn't going to run well on Linux. I have no experience with GTK#.
Mono should be looked at like WINE, useful to port programs to, useful to get some programs to run, but shouldn't be your language of choice if you want to get cross-platform apps.
I write ObjectCloud in C#, test on Mac with Mono, and deploy in on Ubuntu Linux with Mono. My experience with Mono is that it's fast and reliable, as long as you're sticking with the lower-level CLR APIs. IE, it's fine for servers that handle their own sockets; but it's not good for GUI applications.
I use Rackspace Cloud because it's simple. There's nothing to mount, nor is there a huge learning curve with setting up a VM. It's a great way to experiment with servers on a shoestring budget.
However, things change when you're moving from a handful of manually-configured VMs to an army designed to handle lots of load. Amazon's learning curve is certainly worth considering once you need to tune towards an app's specific scalability needs.
So Flash is doing "something" more than hogging the CPU, that Mac OS X or MacBook Air doesn't like. I don't know what.
Could be poorly-designed garbage collection. When done poorly, instead of cleaning themselves up, garbage collected programs will soak up RAM and swap out all your other programs to disk. I see this problem more on PC then on Mac, but I think it's because Apple tends to discourage developing with garbage collection.
Microsoft just rode the wave of open IBM hardware specifications for the business PC. A little knife in the back of things like DRDOS and Microsoft had no competition.
Well, that's not exactly what happened. According to some speech Bill Gates gave in the late 80s or early 90s, (it was posted on Slashdot a few years ago,) he was pretty involved in making the specs for the "open" PC. Bill Gates had a lot more experience building computers then he gets credit for, and he was heavily consulted on what to put in the "open" PC.
... web ads can rob 2 hours from a macbook air's life, the main reason why the battery lasts longer in the no-flash case is because the ads aren't loaded, once all ads move to HTML5 I don't think there'll be that much of a difference.
Doubtful. The real problem is that Apple can't tweak the Flash runtime to be more CPU efficient. In contrast, they can do whatever they want to their Javascript and HTML engines.
This is also why I love Chrome. It buckets Flash into a separate process, so when Ads start hogging the CPU, I kill the Flash process.
And all iPhone consumers in the market will hear about it
But will they care? The problem with our system is that, as consumers, we have to not care or assume that all products are equal in their externalities.
It's like, the only real way to exert change is to embargo any products that aren't manufactured in plants that don't match US safety standards, or a subset thereof.
The words "Apple," "iPhone," and "iPod" do not appear in the summary or summary's title. Is Apple and the iPhone getting so dominant that we can just assume that "The App Store" is alway's Apple's?
Realistically, hard drives slow down computers when the operating system is paging. (For those of us without a CS degree, "paging" is when an operating system uses a hard drive as virtual RAM.) In contrast, the reason why large hard drives is so popular is because people like me like to load them up with tons of video and MP3 files. There's very little performance boost in moving 2-3 TB of MP3s and movies to flash; but there's a huge performance boost in using a flash drive as virtual memory.
I see flash taking off when operating systems are configured to work normally off of a conventional hard drive, but use an additional flash drive merely for paging and potentially storing commonly-used programs.
It's very easy to experiment with these techniques on a full desktop. You can install a flash drive as a second hard drive, and configure Windows to only page to the flash drive. It will run MUCH faster. Likewise, you could install Windows, Mac, or Linux onto a flashdrive, and then mount a hardrive so that it's the "Users" directory.
I use a lot of virtualization on my home computers, primarily so I can run (gasp) Visual Studio on my Macs. I'm not really sure what you're trying to do; virtualizing desktop applications tends to have a bit of a performance hit. It's really best for running applications that your OS doesn't support... Or for testing out "black market" software.
If you're more concerned about being able to back up and restore a computer to a known state, why don't you use Time Machine (Mac) or a Windows / Unix equivalent? I could throw a NAS on my network and point all my macs to it, and get (mostly) the backup situation that you're looking for.
The reason why Java's never updated is that it's automatic updater is annoying. It always shows up as soon as a boot up my computer, and then tells me I need to reboot. Now, given that normal people like to USE their computers; and given that many corporate computers take forever to boot up, something like this is going to remain ignored. Just think, after waiting 5+ minutes while my computer boots up, do you think I'm going to reboot again for something I've never heard of nor, as far as I know, use?
The Java updater needs to be a lot better. It's like that annoying crack addict that hits you up for money every time you walk down the street.
I'll probably get a 3D TV when I can get 3D video games. For now, there's not enough good 3D content; but every time I play a video game I wish it was in true 3D.
This is in contrast to HDTV and DVD. HDTV and DVD benefited from a huge backlog of widescreen moves from the 1960s. I even bought a widescreen tube HDTV because there were so many widescreen DVDs.
I'll believe the Pope on this one when the Catholic Church stops insisting that Jesus was born from a virgin and reincarnated after execution. After 12 years of Catholic school, where science was taught properly, and Adam and Eve was treated as ancient philosophy; I got turned off when it became clear that the Church still can't distinguish fact from fiction about its beginnings.
Of course, since it's ad hoc (computer to computer) it's not actually access to the internet.
Regarding ad-hoc WIFI networks, that's not true. One node on the network needs to act as a proxy.
This is the case if you share an internet connection on a Mac laptop, such as sharing a 3G dongle over WIFI, or sharing a wired internet connection over WIFI. The network will be ad-hoc and will have access to the internet. The same thing applies with the MiWi application on jailbroken iPhones. It creates an ad-hoc network for accessing the internet through the iPhone.
The point of ad-hoc networks is to save battery and CPU resources and be more responsive at the expense of some reliability. In a normal WIFI network, computer-to-computer connections always go through the router. In ad ad-hoc network, computer-to-computer connections go directly between the computers, creating a strange reliability situation when two computers on the network are far away from each other. Of course, if all you're doing is getting on the internet, it's kind of a wash.
The drug cartels in Mexico are more powerful then the Mexican government. Given that pot is harmless, and drugs like coke and meth are about as harmful as chronic smoking, the American demand for drugs is pretty much funding the systematic destruction of the Mexican government around our southern border.
Slashdot Mirror
There shouldn't be mountains of C# to wade through to get data. If so, the implementation is off. The concept, however, I a big fan of. Even when the impedance is high.
Which gets down to the root problem: The developers wrote a mountain of useless C#. ORM really wasn't an appropriate tool for the project, because it just didn't need all of the things that you use ORM for. All that was needed was a simple layer to map ADO results to objects, or even better, a document database.
Another thing to consider is OODBs. I'm going to be looking at db4o pretty soon because this situation is just intolerable. I had a call with Objectivity, but they wanted in the neighborhood of $80K for a 100 client installation on a 4 processor machine with 3 developer licenses, and that's way beyond our budget. Would have probably been perfect for our situation though, due to the way they wrote the code.
Be careful with DB4o. I played with in in 2005-2006, and its object-loading scheme was somewhat confusing. You need to "know" that your in-memory objects can be incomplete, which means that you continually need to activate them.
MongoDB, with their C# drivers, is a very similar "sales pitch" to Objectivity. Both the MongoDB and Objectivity drivers let you work with real C# objects. The reason why I like MongoDB, (in addition to its cost,) is that you can have an entire graph of objects that are persisted to the database as a document, and then you can query the database to get back these objects.
Frankly, the reason why I recommend "document" databases instead of object oriented ones is that, in situations like MongoDB, they pretty much are an object-oriented database, except the "document" aspect means that you don't get into the incomplete object graph issue that db4o put me in.
Parent sounds a little like they were in over their head. Was the problem NHibernate (the implementation) or the ORM (the concept)?
Both.
The problem was rooted in the fact that the engineers who started and lead the project had no clue how to program with a relational database, and treated NHibernate as a magic persistance layer. They would just quote the mantra of "Like Inversion Of Control, Test Driven Design, Policy Injection, Design By Contract" and then totally misunderstand how to act on the concepts.
IE, they would do things like foreach over an entire table instead of "select where parentid=123". They would also suck an entire database into RAM, change 1-2 fields, instead of writing a simple update statement. When it was appropriate to just write a %$@%#$ query, they would write tons of C# that would put a huge load on the database. They would also do things like load tons of objects and pass them around, when all you need are IDs.
So yes, it was a mis-applied tool. But, the issue was complicated that those of us who knew how to use a database just found that NHibernate would get in our way when 100s of lines of C# would be better replaced by a simple stored procedure. IE, NHibernate never added any value, except for simplifying basic CRUD.
In contrast, the most successful database work that I've done had a database programming expert on the team. The vast majority of data manipulation was done in raw SQL with stored procedures, and then we had a simple ORM that helped populate query results and generate wrappers to call stored procedures. There wasn't any framework to get in the way.
I had the misfortune of developing with NHibernate. The root of the problem was that the engineers who started the project didn't know anything about database programming and just used NHibernate as a magic persistance layer. (These guys would write foreach loops that would suck most of the database into RAM.) Ultimately, as I learned the tool, I found that it just makes data access more complicated then it needs to be. In order to use it right, you have to know the underlying database programming concepts, which are simpler and easier to learn then the NHibernate library.
To make matters worse, when I used NHibernate, there was a bug in runtime code generation, which was very hard to track down and impossible to fix.
My opinion: Stick with a simple ADO -> Object mapper and write queries as-needed. If you use NHibernate, stick with the basic CRUD features. Don't rely on a more complicated library to handle things like transactions, lazy-loading, and relationship mapping. Be very careful introducing relationships into the business objects, especially automatically-populated ones. And, whatever you do, if you end up working in a project where the senior engineers and/or people who started the project treat NHibernate as a "magic persistance layer," RUN!!!
Oh, and if you work on a project that wants a "magic persistance layer," because the engineers don't get databases, investigate document databases like MongoDB, Couch, ect. The document model maps a lot better to the object-oriented way of doing things, thus it's a lot harder for programmers who don't get databases to screw them up.
They never make any public info, but it's crazy what kind of logic blocks they find on silicon.
Sometimes scraping can tell simpler things, like an accurate estimate about how much profit a company is making on a chip, and thus how much money the company will have to invest in its next generation of chips.
No, that's understanding the design of the CLR. It allows APIs that are platform specific and APIs that are platform neutral. Assuming that you build against Microsoft-specific or Windows-specific APIs, then you're not going to run well, or at all, on Linux.
When I said GUI, I meant WinForms. I should have been more specific. A WinForms C# App isn't going to run well on Linux. I have no experience with GTK#.
Mono should be looked at like WINE, useful to port programs to, useful to get some programs to run, but shouldn't be your language of choice if you want to get cross-platform apps.
I write ObjectCloud in C#, test on Mac with Mono, and deploy in on Ubuntu Linux with Mono. My experience with Mono is that it's fast and reliable, as long as you're sticking with the lower-level CLR APIs. IE, it's fine for servers that handle their own sockets; but it's not good for GUI applications.
I use Rackspace Cloud because it's simple. There's nothing to mount, nor is there a huge learning curve with setting up a VM. It's a great way to experiment with servers on a shoestring budget.
However, things change when you're moving from a handful of manually-configured VMs to an army designed to handle lots of load. Amazon's learning curve is certainly worth considering once you need to tune towards an app's specific scalability needs.
So Flash is doing "something" more than hogging the CPU, that Mac OS X or MacBook Air doesn't like. I don't know what.
Could be poorly-designed garbage collection. When done poorly, instead of cleaning themselves up, garbage collected programs will soak up RAM and swap out all your other programs to disk. I see this problem more on PC then on Mac, but I think it's because Apple tends to discourage developing with garbage collection.
Microsoft just rode the wave of open IBM hardware specifications for the business PC. A little knife in the back of things like DRDOS and Microsoft had no competition.
Well, that's not exactly what happened. According to some speech Bill Gates gave in the late 80s or early 90s, (it was posted on Slashdot a few years ago,) he was pretty involved in making the specs for the "open" PC. Bill Gates had a lot more experience building computers then he gets credit for, and he was heavily consulted on what to put in the "open" PC.
... web ads can rob 2 hours from a macbook air's life, the main reason why the battery lasts longer in the no-flash case is because the ads aren't loaded, once all ads move to HTML5 I don't think there'll be that much of a difference.
Doubtful. The real problem is that Apple can't tweak the Flash runtime to be more CPU efficient. In contrast, they can do whatever they want to their Javascript and HTML engines.
This is also why I love Chrome. It buckets Flash into a separate process, so when Ads start hogging the CPU, I kill the Flash process.
I'm sure I'm missing something here -- what is it?
HTML is very complicated and ambiguous. "Standards Compliant" relies on judgement calls.
And all iPhone consumers in the market will hear about it
But will they care? The problem with our system is that, as consumers, we have to not care or assume that all products are equal in their externalities.
It's like, the only real way to exert change is to embargo any products that aren't manufactured in plants that don't match US safety standards, or a subset thereof.
The words "Apple," "iPhone," and "iPod" do not appear in the summary or summary's title. Is Apple and the iPhone getting so dominant that we can just assume that "The App Store" is alway's Apple's?
Realistically, hard drives slow down computers when the operating system is paging. (For those of us without a CS degree, "paging" is when an operating system uses a hard drive as virtual RAM.) In contrast, the reason why large hard drives is so popular is because people like me like to load them up with tons of video and MP3 files. There's very little performance boost in moving 2-3 TB of MP3s and movies to flash; but there's a huge performance boost in using a flash drive as virtual memory.
I see flash taking off when operating systems are configured to work normally off of a conventional hard drive, but use an additional flash drive merely for paging and potentially storing commonly-used programs.
It's very easy to experiment with these techniques on a full desktop. You can install a flash drive as a second hard drive, and configure Windows to only page to the flash drive. It will run MUCH faster. Likewise, you could install Windows, Mac, or Linux onto a flashdrive, and then mount a hardrive so that it's the "Users" directory.
I use a lot of virtualization on my home computers, primarily so I can run (gasp) Visual Studio on my Macs. I'm not really sure what you're trying to do; virtualizing desktop applications tends to have a bit of a performance hit. It's really best for running applications that your OS doesn't support... Or for testing out "black market" software.
If you're more concerned about being able to back up and restore a computer to a known state, why don't you use Time Machine (Mac) or a Windows / Unix equivalent? I could throw a NAS on my network and point all my macs to it, and get (mostly) the backup situation that you're looking for.
The summary is wrong. Stanford provides discounted faculty housing. The article doesn't talk about their dorms.
The reason why Java's never updated is that it's automatic updater is annoying. It always shows up as soon as a boot up my computer, and then tells me I need to reboot. Now, given that normal people like to USE their computers; and given that many corporate computers take forever to boot up, something like this is going to remain ignored. Just think, after waiting 5+ minutes while my computer boots up, do you think I'm going to reboot again for something I've never heard of nor, as far as I know, use?
The Java updater needs to be a lot better. It's like that annoying crack addict that hits you up for money every time you walk down the street.
I've met a lot of EFF people. It's kind of funny how unconcerned they are about the government knowing about their personal lives.
I'll probably get a 3D TV when I can get 3D video games. For now, there's not enough good 3D content; but every time I play a video game I wish it was in true 3D.
This is in contrast to HDTV and DVD. HDTV and DVD benefited from a huge backlog of widescreen moves from the 1960s. I even bought a widescreen tube HDTV because there were so many widescreen DVDs.
I'll believe the Pope on this one when the Catholic Church stops insisting that Jesus was born from a virgin and reincarnated after execution. After 12 years of Catholic school, where science was taught properly, and Adam and Eve was treated as ancient philosophy; I got turned off when it became clear that the Church still can't distinguish fact from fiction about its beginnings.
Of course, since it's ad hoc (computer to computer) it's not actually access to the internet.
Regarding ad-hoc WIFI networks, that's not true. One node on the network needs to act as a proxy.
This is the case if you share an internet connection on a Mac laptop, such as sharing a 3G dongle over WIFI, or sharing a wired internet connection over WIFI. The network will be ad-hoc and will have access to the internet. The same thing applies with the MiWi application on jailbroken iPhones. It creates an ad-hoc network for accessing the internet through the iPhone.
The point of ad-hoc networks is to save battery and CPU resources and be more responsive at the expense of some reliability. In a normal WIFI network, computer-to-computer connections always go through the router. In ad ad-hoc network, computer-to-computer connections go directly between the computers, creating a strange reliability situation when two computers on the network are far away from each other. Of course, if all you're doing is getting on the internet, it's kind of a wash.
I agree, but the people who wear them do so because they can pull on the pedal.
The drug cartels in Mexico are more powerful then the Mexican government. Given that pot is harmless, and drugs like coke and meth are about as harmful as chronic smoking, the American demand for drugs is pretty much funding the systematic destruction of the Mexican government around our southern border.