Some info here.
Some info here.
Link to Original Source
This is the same problem we've always had, whether its someone's website on a shared host or a colo server. You need to back it all up and doing a naive dump of the entire thing will take too long and cost too much in bandwidth, so you take a dump of the entire thing once (preferably when you have the thing you're deploying locally) and then take incremental backups from there.
I agree with this approach. If you can get an initial full backup and then use something like RSync with a cron job to handle the incrementals, that would be ideal.
Some info regarding RSync with EC2 is here: http://stackoverflow.com/quest...
One of the worst offenders when it comes to data exports has to be salesforce.com. If you delete a single custom object they charge you upwards of $10K USD to recover your data: https://help.salesforce.com/HT...
Even worse, you get it back in CSV format. My former employer decided to go with them for their entire operation (sales, marketing, and production/warehouse). I left around the time they started implementation, and it was a complete nightmare!
I've used about a dozen of these in various configurations for everything from greenhouse controllers, to high end fish aquarium controllers, to data logging and serving up a web UI for a personal weather station. They've been an excellent price-competitive SBC. So cheap that it's often easier to just swap them out if they fail (I've fried a couple myself).
I designed a small stack of boards that expands the Pi to include:
- A base board with battery-backed RTC, watchdog timer, wide-input switching supply for +5V and +3.3V rails, Dallas/Maxim 1-wire sensor interface, buffered/isolated I2C master as well as a TTL and true RS-232 ports.
- A 16-channel AC driver board for 24-240VAC loads such as contactors and valves
- 32-bit DIO board
- 4-20mA input board (for industrial sensors)
- A prototyping board
You can see an early prototype here: http://www.raspberrypi.org/for...
The new B+ model is supposed to be better since they redesigned the power supply to be a switcher vs. an old linear style design, plus they've doubled the onboard USB ports.
IsItDownRightNow is filling up with users reporting it is down for a wide geographic area: http://www.isitdownrightnow.co...
So far Google's status page is still showing "Green": http://www.google.com/appsstat...
Anyone else seeing this?"
Link to Original Source
- a) Cheaper (even with the "sled", it still costs less than a dedicated device)
- b) It does't run an old proprietary monochrome OS
- c) It's lighter in weight
I recall the customer experience when Apple itself went from the Symbol scanners to the Linea Pro sled + iPod combo as being pretty much night-and-day. The old devices were clunky and slow, and the new were fast and efficient. Being able to sign with your finger onscreen was also a big plus. Paperless receipts are great!
I disagree. For our implementation (see my post above), it was two of us and we managed to connect many disparate applications. As long as you understand what you're interfacing with and sufficient API documentation exists, it's not that difficult. We managed to connect to UPS, FedEx and USPS for shipping label generation/package tracking, Authorize.net for payment processing, DBA Manufacturing (the legacy MRP system we were using) for importing the customers, suppliers, and items, and OpenCart for our web store.
It took the two of us about 12 months of solid work to accomplish this. I'm sure Telsa's ERP system involves a lot of supply-chain connections (good ERP systems need this capability), yet they were able to pull it off in 4 months.
We just went through this exact same exercise at the company I work for. When our antiquated, poorly-designed MRP system started causing too many headaches, we carefully counted the cost of moving to something like Salesforce.com or SAP, but ultimately ended up writing out own system from scratch. After running the two systems in parallel for 6 months to ensure the new system had data integrity we were comfortable with, we cut it off. Having just closed our first month "live" on the new system, I must say it's a real breath of fresh air for both the IS staff and the rest of the company. Gone are the days waiting for the slow moving MRP company to update their slow system to add features or fix bugs for us. Our hands were tied with the old system, and now the door is open to all sorts of possibilities. People are constantly saying "wow, we can do xyz now!" or "this wasn't even possible before with the old system". The daily complaints about the old system have been replaced with daily feature requests and positive comments.
The small team that built it remains on staff, and if something doesn't work, we fix it. If someone requests a feature that makes sense to the overall design goal, we sketch it out, schedule it, and implement it. We carefully weigh everyone's feature requests and implement only those that make sense for the overall "greater good" of the system. That way we keep feature creep down while building something that helps people get their job done faster. In the time between bug fixes and feature request, we are constantly polishing the system to make it more efficient. We now have a DEV environment where we can test out new ideas and features and release them to production only when they are ready.
Since we built ours with FOSS technologies, it's been a joy to integrate with our other trading partners (suppliers, our web store shopping cart, etc). The money we are saving on not having to pay for licensing costs (recurring yearly, never ending), we have invested in hardware and infrastructure to run the new system.
Perhaps the biggest benefit is when the system is released, the company will have a team on staff that knows the system inside and out, because they built it.
I would highly recommend any company considering buying an out-of-the-box ERP system to consider having an in-house team build them a custom solution. With the right group of developers, it can be a really rewarding experience for everyone!
1) Pick a job where you will be involved with writing software/firmware in the manufacturing business. Chances are you will be on your feet for a good part of the day, walking out to the production floor to debug various things.
2) During your daily breaks (most employers allow 2 or 3 of these throughout the day) go for a walk around where you work.
3) Take a "real" lunch where you physically leave the office instead of eating at your desk, reading slashdot. Walk to the eating place or bring your lunch and walk with it and eat it outside. That way you will get sunshine (Vitamin D) and some physical movement as well.
4) To reduce "chair time" further, actually get up and walk over to whomever you need to speak with vs. just dialing them up on the office phone system. Every little bit helps.