Sounds like one of our recent projects. The programming team spent a week debating which PHP framework was the "best" framework for the project. Especially when they got into "does it have a library/module/api for service XYZ?". I got frustrated and hacked together a functional prototype in Perl over that weekend. No frameworks other than CPAN modules. It was admittedly ugly code (I'm the systems guy), but the programmers were able to take my foundation and complete the project about a week ahead of schedule for once. Every time they need some API or function, there seemed to be a Perl Module for it already in CPAN, tested, and pretty much exactly what was needed.
PHP guys are easier to come by these days, but the last few PHP projects I've been involved in, it seems like they spend a lot of time trying out the Popular Framework of the year, only to decide to roll their own. I may be biased, but a lot of the projects seems like they could have been almost done if they just gone with Perl.
But I'm just a systems guy. I'm biased towards Perl because I like getting shit done.
If you read the article, it's the SD card that's infected. Which, no, wouldn't affect an iPhone since there isn't an SD slot. Question is, where did the SD card ship from? Vodoaphone or HTC?
The bigger problem is that this is HTC, who also produces the Nexus for Google proper. Even if the attack vector was an employee at the store, it gives people a moment of pause. When was the last time you saw a Blackberry, Palm, Nokia, LG, Windows Mobile, or iPhone distributed with Malware from the store? (Other than anything with vCast)
People around here love to bitch about Apple and their control over their hand set, but this was one of the reasons they locked it down. Especially in the early days when it wasn't a proven platform. If the iPhone had been a free for all, malware would have quickly popped up and not only killed the iPhone, but like set all smart phones not made by RIM back a few years. But long term I think there is going to be a malware problem on Android and then the Carriers will use that as an excuse to grab back control of the platform forcing users to only use "their App store".
And to those who say, "But don't run unsigned apps from sources you don't know". Yeah, makes perfect sense to me, but how many people do we know downloaded the prettypuppiesscreensaver.exe only to get infected with a virus? How long until we see some tweet linked to an android malware program that thousands of users install because they don't know any better?
You know, the more I get to thinking about it, the more sense Apple's policy of no background apps becomes.
My general experience is that if you stick to the specs, web-apps work pretty well the same way in Safari, FF, Opera, and Chrome. Until Apple turns Webkit into IE, then it's time to look at other platforms. But as I said in the OP, the full browser app renders perfectly on the iPhone/Touch but the screen is too small to make an effective demo.
But Apple's control makes it relatively easy to work with in a small shop. Why? We know exactly what the rules are and have a much smaller number of variations to do QA against. If it works on one iPad, it's going to work on them all. It makes it easy to offer our clients a written guarantee of "This will work with the X version of the iWhatever". To contrast that to Android, we're currently charging clients double the amount for the same guarantee because with Android we have to spend a lot more money on acquiring hardware and QA testing.
I'm not so sure, because this is exactly the type of device we've been looking for to give to our sales reps. We have a web-app product we like to demo to people. Potential customers usually don't like playing with the app when it's on a sales rep laptop or netbook. Many of the people I think have a fear of using somebody elses computer and they'll "screw something up". Plus it costs us $60 per month per sales rep for the wireless cards. We tried using iPod Touches/iPhones for demos, but the screens are too small.
These devices seem to be perfect. Its a lot easier and I'm going to say less intimidating for reps to carry into demos, especially initial calls, and $30 per month is cheaper than $60 per month.
People often have a fear of computers. We noticed that when we handed over an iPod Touch with the demo, people were more willing to pick it up and play around with it. It was perfect for demoing the Mobile version of the application, but horrible to show the full browser version.
I think it will play well out in the general market. You just have to realize that the general market is not the slashdot crowd.
With our last website design for our shopping cart, we elected to go with a fluid layout and use em. Great right? Nope. We heard so many complaints from customers it was rather eye-opening. The fact that things were "a little different" from screen to screen (say a desktop vs laptop) annoyed and confused people even if a box was just had more space in between. Frankly we couldn't see it. If the screen was wider, there was a bit more separation in places. So we ended up going back and defining everything being centered and by pixels so it looked the exact same no matter if the user had a 12.1" screen or 30" LCD TV. If they had a bigger screen/higher resolution, they just got to see more of the background gradient. The complaints stopped and we didn't alter the design. So go figure....
We also have clients who are insanely anal about their branding and virtually demand things to be "pixel" perfect. With the iPhone/iPod Touch this hasn't been a problem. Android it has. Not to mention the other hardware inconsistencies.
But in our shop, Android is really starting to cost us a lot of money in QA testing. And we guarantee that our software works on all known models as of a certain date. It's in the contract and the clients do pay us well for it. Our testing hardware for the iPhone/iPod Touch has been $1600 over the past two years. (iPhone 3G, iPhone 3Gs, iPod Touch). We've spent over $2500 acquiring Android hardware just in the last six months of last year and have already spent another $1400 this year.
As a result, the cost of us building an Android app is now double that of an iPhone app. And at the rate the new Android phones are coming out, that is likely to increase if customers want a full compatibility guarantee.
Now we're about to launch our first application built using the PhoneGap framework. It's basically a web app wrapped using PhoneGap's "container" (for lack of better description) and should allow us to support iPhone, Blackberry, and Android by only having to support 1 framework and using web programming. But we'll see how well that works.
Mod parent up. I come from the same SI background and now running a programming shop. What dumbfounded me were the folks with CS degrees that really had no idea how the networking/systems side worked. I can remember a few times they'd call me over after working half a day or more trying to figure out why something in their code wasn't working only to have me take a look and in less than 30 seconds figure out it something on the server wasn't running or there was a network configuration problem.
We have our internal network on separate subnet from the public wiki. Even then, people have to register their MAC address to get internet time. However, all the terminals are all wired connections.
I believe the last version was based on FreeBSD 7 and ZFS support was still experimental. The first production ready build of ZFS on BSD is version 8. So I would imagine that it would be less buggy.
We've had this for well over a decade in FreeBSD, it's called Ports. It may not be GUI, but going cd/usr/ports/whatever/i/want make install clean isn't that hard.
It's taken us also 3 years to take an idea and turn it into a viable product. If we were to use your patent system, all that hard work would have been for not, because just as we got ready to start selling it.
FreeBSD fully supports ZFS and DTRACE in version 8. Version 7 ZFS was still listed as experimental. I know we looked at OpenSolaris, but once those features were in FreeBSD, we decided to stick with what we had. (That being said, we're still running FBSD 6.x on the production machines)
We deploy PostgreSQL at pair networks and then a root server at another hosting company. In the case of pair, we do all the admin from the console. In the case of the other hosting company we use Plesk. Plesk seems to handle it quite nicely and uses phpPGadmin for its web-based administration.
I've also used PostgreSQL with Cpanel with similar results. This seems to be a GoDaddy problem, not a PostgreSQL problem.
And if you have to store credit cards for ecommerce, those last two are out of the question. Virtual servers are not PCI compliant and no "cloud" provider will guarantee PCI Level-I compliance in writing.
Ditto. We rely on Pair Networks for our primary system, but we do have a back up with a different provider and we do our own back ups just in case. The secondary system is not as powerful, but we rsync nightly and run Bucardo to do DB syncing every 15 minutes.
Diddo on Pair Networks. I've been using them for both hosting and for dedicated servers for 10 years. The longest I've ever been on with tech support was 12 minutes. That's not hold, that was the time from when I picked up the phone until the problem was solved. They are consistently in the top 10 of up times in Netcrafts list month after month. And they are 100% FreeBSD. If the server has a hardware problem, they don't bitch. They get everything transferred to a new box and usually within minutes.
Buy an SSL, it's installed and up and running in less than an hour from purchase.
My list of cons: Mail system is a bit restrictive. You have to check email then you have a 90 minute window to send. You can't write off-line and then it will not send until you've checked your email first.
VPS and Dedicated servers are managed only. You do not have root access. If you need anything beyond their standard config, it's $50 a pop to install PostgreSQL or extra Perl Modules. That being said, almost any Perl module you'd want is already installed. And the price for not having to worry about security patches and other problems...worth the one time $50 fee.
We use them for all our production servers. Compared to what we had in development from another provider, lightyears beyond. Yes the other provider was $99 vs. $300 per month per server, but at Pair we've had 0 downtime other than scheduled maintenance to upgrade the server os.
(I don't work for them. I'm just a very, very happy client)
This is true. Right I'm working on a project for a company that has a Cobol inventory and purchasing system that has worked for them for 35 years. Now they want E-Commerce and we're having to figure out a way to make it work. They aren't even using a RDBMS, it's just an ISAM file. We talked about moving them to OpenBravoERP as our E-Commerce system already works with their POS and it would be easy (orders go into the POS and then are synced with the ERP).
But they have the opinion of "it's worked for 35 years why change?". I imagine it will change in the next decade. Their Cobol programmer is 66. Somehow I doubt he's going to want to work on it much longer. Or dies.
Slashdot Mirror
Sounds like one of our recent projects. The programming team spent a week debating which PHP framework was the "best" framework for the project. Especially when they got into "does it have a library/module/api for service XYZ?". I got frustrated and hacked together a functional prototype in Perl over that weekend. No frameworks other than CPAN modules. It was admittedly ugly code (I'm the systems guy), but the programmers were able to take my foundation and complete the project about a week ahead of schedule for once. Every time they need some API or function, there seemed to be a Perl Module for it already in CPAN, tested, and pretty much exactly what was needed.
PHP guys are easier to come by these days, but the last few PHP projects I've been involved in, it seems like they spend a lot of time trying out the Popular Framework of the year, only to decide to roll their own. I may be biased, but a lot of the projects seems like they could have been almost done if they just gone with Perl.
But I'm just a systems guy. I'm biased towards Perl because I like getting shit done.
If you read the article, it's the SD card that's infected. Which, no, wouldn't affect an iPhone since there isn't an SD slot. Question is, where did the SD card ship from? Vodoaphone or HTC?
The bigger problem is that this is HTC, who also produces the Nexus for Google proper. Even if the attack vector was an employee at the store, it gives people a moment of pause. When was the last time you saw a Blackberry, Palm, Nokia, LG, Windows Mobile, or iPhone distributed with Malware from the store? (Other than anything with vCast)
People around here love to bitch about Apple and their control over their hand set, but this was one of the reasons they locked it down. Especially in the early days when it wasn't a proven platform. If the iPhone had been a free for all, malware would have quickly popped up and not only killed the iPhone, but like set all smart phones not made by RIM back a few years. But long term I think there is going to be a malware problem on Android and then the Carriers will use that as an excuse to grab back control of the platform forcing users to only use "their App store".
And to those who say, "But don't run unsigned apps from sources you don't know". Yeah, makes perfect sense to me, but how many people do we know downloaded the prettypuppiesscreensaver.exe only to get infected with a virus? How long until we see some tweet linked to an android malware program that thousands of users install because they don't know any better?
You know, the more I get to thinking about it, the more sense Apple's policy of no background apps becomes.
My general experience is that if you stick to the specs, web-apps work pretty well the same way in Safari, FF, Opera, and Chrome. Until Apple turns Webkit into IE, then it's time to look at other platforms. But as I said in the OP, the full browser app renders perfectly on the iPhone/Touch but the screen is too small to make an effective demo.
But Apple's control makes it relatively easy to work with in a small shop. Why? We know exactly what the rules are and have a much smaller number of variations to do QA against. If it works on one iPad, it's going to work on them all. It makes it easy to offer our clients a written guarantee of "This will work with the X version of the iWhatever". To contrast that to Android, we're currently charging clients double the amount for the same guarantee because with Android we have to spend a lot more money on acquiring hardware and QA testing.
I'm not so sure, because this is exactly the type of device we've been looking for to give to our sales reps. We have a web-app product we like to demo to people. Potential customers usually don't like playing with the app when it's on a sales rep laptop or netbook. Many of the people I think have a fear of using somebody elses computer and they'll "screw something up". Plus it costs us $60 per month per sales rep for the wireless cards. We tried using iPod Touches/iPhones for demos, but the screens are too small.
These devices seem to be perfect. Its a lot easier and I'm going to say less intimidating for reps to carry into demos, especially initial calls, and $30 per month is cheaper than $60 per month.
People often have a fear of computers. We noticed that when we handed over an iPod Touch with the demo, people were more willing to pick it up and play around with it. It was perfect for demoing the Mobile version of the application, but horrible to show the full browser version.
I think it will play well out in the general market. You just have to realize that the general market is not the slashdot crowd.
Why would Oracle buy Novell for linux when Oracle now has Solaris?
What do you do when your on an airplane and don't have internet or the DSL/Cable connection goes down for an afternoon at the office?
Until there are versions of Google Docs that you can use off line, it's a no go.
With our last website design for our shopping cart, we elected to go with a fluid layout and use em. Great right? Nope. We heard so many complaints from customers it was rather eye-opening. The fact that things were "a little different" from screen to screen (say a desktop vs laptop) annoyed and confused people even if a box was just had more space in between. Frankly we couldn't see it. If the screen was wider, there was a bit more separation in places. So we ended up going back and defining everything being centered and by pixels so it looked the exact same no matter if the user had a 12.1" screen or 30" LCD TV. If they had a bigger screen/higher resolution, they just got to see more of the background gradient. The complaints stopped and we didn't alter the design. So go figure....
We also have clients who are insanely anal about their branding and virtually demand things to be "pixel" perfect. With the iPhone/iPod Touch this hasn't been a problem. Android it has. Not to mention the other hardware inconsistencies.
But in our shop, Android is really starting to cost us a lot of money in QA testing. And we guarantee that our software works on all known models as of a certain date. It's in the contract and the clients do pay us well for it. Our testing hardware for the iPhone/iPod Touch has been $1600 over the past two years. (iPhone 3G, iPhone 3Gs, iPod Touch). We've spent over $2500 acquiring Android hardware just in the last six months of last year and have already spent another $1400 this year.
As a result, the cost of us building an Android app is now double that of an iPhone app. And at the rate the new Android phones are coming out, that is likely to increase if customers want a full compatibility guarantee.
Now we're about to launch our first application built using the PhoneGap framework. It's basically a web app wrapped using PhoneGap's "container" (for lack of better description) and should allow us to support iPhone, Blackberry, and Android by only having to support 1 framework and using web programming. But we'll see how well that works.
Mod parent up. I come from the same SI background and now running a programming shop. What dumbfounded me were the folks with CS degrees that really had no idea how the networking/systems side worked. I can remember a few times they'd call me over after working half a day or more trying to figure out why something in their code wasn't working only to have me take a look and in less than 30 seconds figure out it something on the server wasn't running or there was a network configuration problem.
We have our internal network on separate subnet from the public wiki. Even then, people have to register their MAC address to get internet time. However, all the terminals are all wired connections.
I wouldn't use wireless to transmit cc-details.
I believe the last version was based on FreeBSD 7 and ZFS support was still experimental. The first production ready build of ZFS on BSD is version 8. So I would imagine that it would be less buggy.
We've had this for well over a decade in FreeBSD, it's called Ports. It may not be GUI, but going cd /usr/ports/whatever/i/want make install clean isn't that hard.
Thing is, I've yet to get a site to render correctly in webkit (Safari) that didn't also render and function the same way with FF or Opera.
It's taken us also 3 years to take an idea and turn it into a viable product. If we were to use your patent system, all that hard work would have been for not, because just as we got ready to start selling it.
FreeBSD fully supports ZFS and DTRACE in version 8. Version 7 ZFS was still listed as experimental. I know we looked at OpenSolaris, but once those features were in FreeBSD, we decided to stick with what we had. (That being said, we're still running FBSD 6.x on the production machines)
More like the exact same problem as Windows Mobile, only Windows Mobile doesn't seem to have a different version every three months.
I thought they were the ones who told the rebel alliance about the second Death star at endor....IT'S A TRAP.
We deploy PostgreSQL at pair networks and then a root server at another hosting company. In the case of pair, we do all the admin from the console. In the case of the other hosting company we use Plesk. Plesk seems to handle it quite nicely and uses phpPGadmin for its web-based administration.
I've also used PostgreSQL with Cpanel with similar results. This seems to be a GoDaddy problem, not a PostgreSQL problem.
You mean phpPGAdmin? I don't find it hogs any more memory than phpMyAdmin. Now we can use pgAdmin II on the desktop to connect if we want.
What's the write off for "Good Will" from this?
And if you have to store credit cards for ecommerce, those last two are out of the question. Virtual servers are not PCI compliant and no "cloud" provider will guarantee PCI Level-I compliance in writing.
Ditto. We rely on Pair Networks for our primary system, but we do have a back up with a different provider and we do our own back ups just in case. The secondary system is not as powerful, but we rsync nightly and run Bucardo to do DB syncing every 15 minutes.
Diddo on Pair Networks. I've been using them for both hosting and for dedicated servers for 10 years. The longest I've ever been on with tech support was 12 minutes. That's not hold, that was the time from when I picked up the phone until the problem was solved. They are consistently in the top 10 of up times in Netcrafts list month after month. And they are 100% FreeBSD. If the server has a hardware problem, they don't bitch. They get everything transferred to a new box and usually within minutes.
Buy an SSL, it's installed and up and running in less than an hour from purchase.
My list of cons:
Mail system is a bit restrictive. You have to check email then you have a 90 minute window to send. You can't write off-line and then it will not send until you've checked your email first.
VPS and Dedicated servers are managed only. You do not have root access. If you need anything beyond their standard config, it's $50 a pop to install PostgreSQL or extra Perl Modules. That being said, almost any Perl module you'd want is already installed. And the price for not having to worry about security patches and other problems...worth the one time $50 fee.
We use them for all our production servers. Compared to what we had in development from another provider, lightyears beyond. Yes the other provider was $99 vs. $300 per month per server, but at Pair we've had 0 downtime other than scheduled maintenance to upgrade the server os.
(I don't work for them. I'm just a very, very happy client)
This is true. Right I'm working on a project for a company that has a Cobol inventory and purchasing system that has worked for them for 35 years. Now they want E-Commerce and we're having to figure out a way to make it work. They aren't even using a RDBMS, it's just an ISAM file. We talked about moving them to OpenBravoERP as our E-Commerce system already works with their POS and it would be easy (orders go into the POS and then are synced with the ERP).
But they have the opinion of "it's worked for 35 years why change?". I imagine it will change in the next decade. Their Cobol programmer is 66. Somehow I doubt he's going to want to work on it much longer. Or dies.