The devices in your image are all outdated pre-chip-card readers. There's a newer bluetooth-capable reader available from nearly every one of those vendors.
Outside of increasingly niche situations, it seems like there's no future in being the ones "making stuff" at a company. Get promoted to management before you get outsourced is the name of the game.
There's an open source platform, BOTS, that you may want to look into before you get too far. http://bots.sourceforge.net/en... It has a bit of a learning curve, but we use it to send and receive tens of thousands of 214s a day. We also send and receive 204, 210, 990, 997, 850, 855 as well as invoking carrier-specific webservices. We also use BOTS for just FTPing files from here to there, because its self-monitoring with auto-retry. It's pretty much the only functional OSS EDI solution but its way better than rolling your own. The only real downside to it is its main processing engine is a singleton, but that wouldn't be an issue unless you were processing tremendous amounts of EDI. In any case, it's better than rolling your own solution.
I see what you mean. I think it's just too close to home for me, seeing the downside to it. Most recently it was legacy SQL Server SSIS code that called a web service. The web service added a new requirement for a SOAP Signature. The signature hash method is only supported in.NET 4.5 or 4.6 (don't recall which( but SSIS doesn't support any version above 4.0 . Then, on the linux side of things, I also have a team that loves to write their business logic in Postgresql's PG/PLSQL versus on their C# layer.. PG/PLSQL is fairly primitive and they're calling web services and TCP socket servers from inside it. The resultant code is verbose and difficult to follow. Plus it has no capability to run on anything other than a single core.
This is a bad idea because, generally, the database is the most difficult and most costly layer to scale. Like one of the downstream comments said, data and validation, yes. But the CPU cycles spent on general business logic are better placed on a higher layer.
At least one of the well-known open source RBDMSs seems to fall apart if normalization results in queries with a large number of joins. The planner can't effectively handle queries of anything other than basic complexity if there's more than 12-16 joins. Couple that with no shared plan cache and denormalization becomes one of the only options.
Even as a stale troll, this is hilarious. "I'd always done my work on Windows" but the best solution for their client, when using Linux, is for them to immediate start mucking with the kernel source.
25 year veteran here and you've made a pile of ASSumptions. I'm aware that Git works and I'm aware that, compared to SVN, it's a complete shift in the way merging is addressed. This makes perfect sense for Linux kernel development but doesn't necessarily map well onto every type of software development.
For my team, it just added complexity with no benefit. Team's workflow with SVN was "update early and often". Commit changes. That was basically it. With Git it's been an insane nightmare. The only thing I can figure is that either most teams use the "gateway" merging model, where one person does most of the merging, or the teams do not frequently have multiple developers working in the same files. Under years of SVN, merging was a nonissue for the team. Under Git, there's always some sort of drama.
Do you have a source for the theory that inventory from multiple sellers is commingled? That would make for some interesting inventory control issues. The reason the reviews are mixed is because the reviews _are_ commingled by ASIN, regardless of seller.
It's not really a rebrand, it's apparently a total rewrite... which is the entire problem. It seems to freeze up frequently for many people and it's missing plugin support in the release version.
Great post... I find that many people who think Git is simple to use are working with it in a nearly non-concurrent development environment where multiple developers rarely touch the same source file, or they're using the gatekeeper paradigm.
Yamaha recentlyupdated their driver for a bunch of the Steinberg USB hardware to supposedly work around an issue where USB chipsets were outputting data that was out of spec. The relnotes say "Audio loss may occur if a Steinberg audio interface is connected to an USB port of the PC which is controlled by one of the specific USB controller chips inside the PC. This sometimes occurs due to the software of the USB controller to return abnormal values to our audio driver."
You want to hear a staggering statistic? Magic Jack has more subscribers than Indiantown Telephone Company. It's hard to believe that Magic Jack, introduced in 2007, was selling nearly 10,000 units PER DAY whereas Indiantown Telephone Company, established in 1930, still hasn't managed to break the 10,000 subscriber mark, period!
Many utilities operate on a "cost plus" model, so there's actually a huge incentive to modernize the grid, or basically incur as much cost as the regulators will let the utility get away with. Even worse, when the regulated arm engages in expansion or modernization, it contracts with its unregulated "utility construction services" arm.
Slashdot Mirror
The devices in your image are all outdated pre-chip-card readers. There's a newer bluetooth-capable reader available from nearly every one of those vendors.
Outside of increasingly niche situations, it seems like there's no future in being the ones "making stuff" at a company. Get promoted to management before you get outsourced is the name of the game.
Exactly, same way Google+ destroyed Facebook.
There's an open source platform, BOTS, that you may want to look into before you get too far. http://bots.sourceforge.net/en... It has a bit of a learning curve, but we use it to send and receive tens of thousands of 214s a day. We also send and receive 204, 210, 990, 997, 850, 855 as well as invoking carrier-specific webservices. We also use BOTS for just FTPing files from here to there, because its self-monitoring with auto-retry. It's pretty much the only functional OSS EDI solution but its way better than rolling your own. The only real downside to it is its main processing engine is a singleton, but that wouldn't be an issue unless you were processing tremendous amounts of EDI. In any case, it's better than rolling your own solution.
I see what you mean. I think it's just too close to home for me, seeing the downside to it. Most recently it was legacy SQL Server SSIS code that called a web service. The web service added a new requirement for a SOAP Signature. The signature hash method is only supported in .NET 4.5 or 4.6 (don't recall which( but SSIS doesn't support any version above 4.0 . Then, on the linux side of things, I also have a team that loves to write their business logic in Postgresql's PG/PLSQL versus on their C# layer.. PG/PLSQL is fairly primitive and they're calling web services and TCP socket servers from inside it. The resultant code is verbose and difficult to follow. Plus it has no capability to run on anything other than a single core.
The 20 year old devices were made better.
Just buy one, building one is a fool's errand.
Beware, the resultant query plan will probably suck.
Facebook _did_ resort to C++ for a period of time, look up HipHop for PHP.
This is a bad idea because, generally, the database is the most difficult and most costly layer to scale. Like one of the downstream comments said, data and validation, yes. But the CPU cycles spent on general business logic are better placed on a higher layer.
At least one of the well-known open source RBDMSs seems to fall apart if normalization results in queries with a large number of joins. The planner can't effectively handle queries of anything other than basic complexity if there's more than 12-16 joins. Couple that with no shared plan cache and denormalization becomes one of the only options.
Even as a stale troll, this is hilarious. "I'd always done my work on Windows" but the best solution for their client, when using Linux, is for them to immediate start mucking with the kernel source.
25 year veteran here and you've made a pile of ASSumptions. I'm aware that Git works and I'm aware that, compared to SVN, it's a complete shift in the way merging is addressed. This makes perfect sense for Linux kernel development but doesn't necessarily map well onto every type of software development.
For my team, it just added complexity with no benefit. Team's workflow with SVN was "update early and often". Commit changes. That was basically it. With Git it's been an insane nightmare. The only thing I can figure is that either most teams use the "gateway" merging model, where one person does most of the merging, or the teams do not frequently have multiple developers working in the same files. Under years of SVN, merging was a nonissue for the team. Under Git, there's always some sort of drama.
A reasonable takeaway from this might be that that overly thorough testing of backup power systems can carry excessive risk.
Millennials are obsessed with side hustles solely so they can use the phrase "side hustle".
Wow, insane. That does seem like it would create a huge issue where counterfeit products could be mixed with legit. Thanks for the OP and reply.
Do you have a source for the theory that inventory from multiple sellers is commingled? That would make for some interesting inventory control issues. The reason the reviews are mixed is because the reviews _are_ commingled by ASIN, regardless of seller.
It's not really a rebrand, it's apparently a total rewrite... which is the entire problem. It seems to freeze up frequently for many people and it's missing plugin support in the release version.
Great post... I find that many people who think Git is simple to use are working with it in a nearly non-concurrent development environment where multiple developers rarely touch the same source file, or they're using the gatekeeper paradigm.
ImageMagick is as old as the hills...
Yamaha recentlyupdated their driver for a bunch of the Steinberg USB hardware to supposedly work around an issue where USB chipsets were outputting data that was out of spec. The relnotes say "Audio loss may occur if a Steinberg audio interface is connected to an USB port of the PC which is controlled by one of the specific USB controller chips inside the PC. This sometimes occurs due to the software of the USB controller to return abnormal values to our audio driver."
You want to hear a staggering statistic? Magic Jack has more subscribers than Indiantown Telephone Company. It's hard to believe that Magic Jack, introduced in 2007, was selling nearly 10,000 units PER DAY whereas Indiantown Telephone Company, established in 1930, still hasn't managed to break the 10,000 subscriber mark, period!
If Pepco was surprised by the deal being rejected the first couple of times, it certainly helps to explain why they're the one being absorbed.
Many utilities operate on a "cost plus" model, so there's actually a huge incentive to modernize the grid, or basically incur as much cost as the regulators will let the utility get away with. Even worse, when the regulated arm engages in expansion or modernization, it contracts with its unregulated "utility construction services" arm.