Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment: You need to care (among other things)... (Score 2) 214

by m2pc (#48920759) Attached to: Ask Slashdot: What Makes a Great Software Developer?

IMHO, a good developer needa to CARE about what he/she is writing. Here are some points I've gathered from two decades of development work:

Care about the code
The quality of the code, efficiency, consistency are all key. Internal documentation is very important. Even if you don't think anyone will *ever* look at that code again, guess again. Someone will probably end up going back over it in the future to fix a bug or add a feature -- often times that is YOU, the one who wrote it. So leave enough comments behind to tell the next guy (or you when you've long forgotten that code) what in the world you were thinking. I've known way too many developers that simply say "yes sir" to their boss and crank out the code as fast as possible. They don't bother to think for themselves things like "what would the customer want" or "how can I design this to be as efficient as possible but still be understandable"? People who view development as simply a "day job" and don't take pride in their work end up causing themselves and others pain down the road. Being a developer should be more than simply writing code that works. You should care enough to write code that works and is elegant.

Care about the end user
Whether your code is a script that nobody will ever see, or a GUI application that people will use daily, a good developer puts themselves in the customer's perspective. They care about efficiency. They care about how the people who will use their software on a daily basis will perceive it, and how it will impact their workflow. Try to imagine how shaving even a few seconds off a process that someone does many times a day could add up over the years. With the power of modern computing, it's all too easy to become lazy as a developer and not put much thought into scalability, or to write sloppy code that doesn't make good use of resources.

Care about robustness and security
Writing good code also involves covering yourself in terms of error trapping. Make sure your code can (attempt to at least) fail gracefully when the unexpected occurs. Also, make sure you always code with a view to security. Way too much software is written in such a way where security and error trapping is put off until later. All too many times, due to time constraints or simply forgetting, these tasks never get done, and as a result insecure, buggy software is released.

Don't be afraid to start over
Good developers also aren't afraid to refactor their code. Sometimes it takes finishing a good chunk of code and analyzing how it performs in the real world to realize you did it all wrong and you need to rip it up and redo it. That's OK. Try to learn from it and do it less as you mature as a developer.

Memorize the headers and APIs you use most
Try to memorize headers and such of key APIs and libraries you use often. Personally, I find it all to easy just to keep looking up that function over and over whenever I need to use it. But if you trust yourself and memorize the documentation, then you can code more efficiently with less interruptions from having to go and look up that function call every time.

Keep it simple
It's easy for a developer to code "the kitchen sink" and bombard the user with a million options and settings. Yes, the program can do everything someone could possibly want, but overwhelming and confusing the end user is never a good idea. It's much better to think things through carefully and build only what is necessary, or if all the options must exist, build it in layers so the most important options are visible first, then the advanced users can dig in and configure to their heart's content.

Comment: BMW (Score 4, Interesting) 195

by m2pc (#48435571) Attached to: Ask Slashdot: What's the Most Hackable Car?
Most of the BMWs from the 90's onward are fairly hackable. You can find copies of the dealer software and production line tools on the web, and tools like NavCoder and similar allow you to control tons of the "convenience" features. Most of the modules have had their options decoded by interested individuals wanting to customize their vehicles.

Some info here.

+ - CurrentC Breached->

Submitted by tranquilidad
tranquilidad writes: As previously discussed in Slashdot, CurrentC is a consortium of merchants attempting to create a 'more secure' payment system. Some controversy surrounds CurrentC's requirements regarding the personal information required, their purchase-tracking intentions and retail stores blocking NFC in apparent support of CurrentC. Now news breaks that CurrentC has already been breached. CurrentC has issued the standard response, "We take the security of our users' information extremely seriously."
Link to Original Source

Comment: Re:incremental backups (Score 2) 150

by m2pc (#48151877) Attached to: If Your Cloud Vendor Goes Out of Business, Are You Ready?

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!

Comment: Re:Industrial Automation (Score 1) 146

by m2pc (#48135277) Attached to: Raspberry Pi Sales Approach 4 Million
Granted, I wouldn't recommend the Pi in an extreme environment where an error could lead to loss of human life or cause severe damage, but as an inexpensive controller for small operations, it works great. A company I used to work for is using them for test automation, and so far they have been very stable and a great little SBC for that task.

Comment: Industrial Automation (Score 1) 146

by m2pc (#48132149) Attached to: Raspberry Pi Sales Approach 4 Million
These are great little boards for industrial automation projects!

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.

Comment: Re:Before anybody complains (Score 1) 75

by m2pc (#45843565) Attached to: Postal Service Starting To Use Mobile Point of Sale Tech
Ive seen several "brick-n-mortar" retailers use similar tech, and the overall experience has been a good one. I remember the days when all that was available was a Symbol-branded monochome "gun" with a huge bulky keypad and display... Having an iPod Touch is actually a lot better all around:
  • 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!

Comment: Re:Here is your answer... (Score 2) 231

by m2pc (#45333939) Attached to: How Elon Musk Approaches IT At Tesla

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.

Comment: Re:A risky gamble (Score 2, Informative) 231

by m2pc (#45329209) Attached to: How Elon Musk Approaches IT At Tesla

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!

Comment: Net Loss (Score 2) 200

by m2pc (#44782921) Attached to: New Jersey Congressman Seeks To Bar NSA Backdoors In Encryption
The fact (if it can ever be concretely proven as such) that the NSA has influenced the encryption algorithms to make them less secure has completely undermined the fundamental trust that was intentionally put in place to allow secure online transactions to occur. Without this trust, much of the value of the Internet is lost. SSL is based on a specific chain of trust from the browser all the way to the Certifying Authority and the entities that allow them to act as such. If this chain is indeed broken as is suspected, then there is a major problem that needs to be fixed.

I'm a Lisp variable -- bind me!

Working...