snydeq writes: "Deep End's Paul Venezia waxes philosophical about Perl stagnancy in IT. 'A massive number of tools and projects still make the most out of the language. But it's hard to see Perl regaining its former glory without a dramatic turnaround in the near term. As more time goes by, Perl will likely continue to decline in popularity and cement its growing status as a somewhat arcane and archaic language, especially as compared to newer, more lithe options. Perhaps that's OK. Perl has been an instrumental part of the innovation and technological advancements of the last two decades, and it's served as a catalyst for a significant number of other languages that have contributed heavily to the programming world in general.'"
snydeq writes: Andrew C. Oliver warns that rolling your own code can often be a waste of time and money. 'Many developers like to create software from scratch, even when there's perfectly good reusable code from other projects, open source, or even commercial products available to do the job.... Whatever the reason, rolling your own code can be a waste of time and effort, as well as an opportunity for bugs to creep in — after all, new code is more likely to have bugs than existing code that's been reviewed and tested,' Oliver writes, offering a look at nine types of software projects that really shouldn't be roll-your-own efforts.
snydeq writes: "You don't need to be a programmer, but you'll solve harder problems faster if you can write your own code, writes Paul Venezia. 'The fact is, while we may know several programming languages to varying degrees, most IT ninjas aren't developers, per se. I've put in weeks and months of work on various large coding projects, but that's certainly not how I spend most of my time. Frankly, I don't think I could just write code day in and day out, but when I need to develop a tool to deal with a random problem, I dive right in.... It's not a vocation, and it's not a clear focus of the job, but it's a substantial weapon when tackling many problems. I'm fairly certain that if all I did was write Perl, I'd go insane.'"
snydeq writes: "Native, Web, or hybrid — choosing the right path for mobile business app development can be tricky business, as no one tool offers the trifecta of fast, cheap, feature-rich app delivery, writes Mel Beckman in a primer for IT organizations in choosing the right mobile development kit for your needs. 'Carefully assessing your prospective app's current and future requirements is key, as is balancing those requirements with the time it takes to get your app to market. Don't feel you have to choose a single platform for every app. It's reasonable to employ multiple development platforms to meet a variety of delivery requirements.'"
snydeq writes: "Self-taught technologists are almost always better hires than those with a bachelor's degree in computer science and a huge student loan, writes Andrew Oliver. 'A recruiter recently asked me why employers are so picky. I explained that of the people who earned a computer science degree, most don't know any theory and can't code. Instead, they succeed at putting things on their resume that match keywords. Plus, companies don't consider it their responsibility to provide training or mentoring. In fairness, that's because the scarcity of talent has created a mercenary culture: "Now that my employer paid me to learn a new skill, let me check to see if there's an ad for it on Dice or Craigslist with a higher rate of pay." When searching for talent, I've stopped relying on computer science degrees as an indicator of anything except a general interest in the field. Most schools suck at teaching theory and aren't great at Java instruction, either. Granted, they're not much better with any other language, but most of them teach Java.'"
snydeq writes: "You want the best and the brightest money can buy. Or do you? Andrew Oliver offers six hard truths about 'rock-star' developers, arguing in favor of mixed skill levels with a focus on getting the job done: 'A big, important project has launched — and abruptly crashed to the ground. The horrible spaghetti code is beyond debugging. There are no unit tests, and every change requires a meeting with, like, 40 people. Oh, if only we'd had a team of 10 "rock star" developers working on this project instead! It would have been done in half the time with twice the features and five-nines availabilty. On the other hand, maybe not. A team of senior developers will often produce a complex design and no code, thanks to the reasons listed below.'"
snydeq writes: "So you think you know PHP, the first choice for anyone putting up a website? From valid array use, to exceptions, to error logging, here are 20 questions that dig into the nuances of one of the Web's most popular means of adding intelligence to your HTML files."
snydeq writes: "'Regardless of where you stand on Anonymous' tactics, politics, or whatever, I think the group has something to teach developers and development organizations,' writes Andrew Oliver. 'As leader of an open source project, I can revoke committer access for anyone who misbehaves, but membership in Anonymous is a free-for-all. Sure, doing something in Anonymous' name that even a minority of "members" dislike would probably be a tactical mistake, but Anonymous has no trademark protection under the law; the organization simply has an overall vision and flavor. Its members carry out acts based on that mission. And it has enjoyed a great deal of success — in part due to the lack of central control. Compare this to the level of control in many corporate development organizations. Some of that control is necessary, but often it's taken to gratuitous lengths. If you hire great developers, set general goals for the various parts of the project, and collect metrics, you probably don't need to exercise a lot of control to meet your requirements.'"
snydeq writes: "The Olympic decathlon may do well in measuring athletic prowess, but it doesn't come close to gauging the intestinal fortitude, quick thinking, and pure endurance programmers display at the keyboard every day. From the Cobol-to-Node migration, to the Requirements Tug-of-War, to the Big Data Profit Toss, the Programming Decathlon is a true test of mental acuity, grace, and genius. Let's see one of those running, jumping, tossing billboards for shoe companies complete even one event.'"
snydeq writes: "Andrew Oliver provides a succinct overview to help interested developers figure out where to begin with the growing number of NoSQL data stores available today. 'Part of the reason there are so many different types of NoSQL databases lies in the CAP theorem, aka Brewer's Theorem. The CAP theorem states you can provide only two out of the following three characteristics: consistency, availability, and partition tolerance. Different datasets and different runtime rules cause you to make different trade-offs. Different database technologies focus on different trade-offs. The complexity of the data and the scalability of the system also come into play. Another reason for this divergence can be found in basic computer science or even more basic mathematics. Relational databases are based on relational algebra, which is more or less an outgrowth of set theory. Relationships based on set theory are effective for many datasets, but where parent-child or distance of relationships are required, set theory isn't very effective. You may need graph theory to efficiently design a data solution. In other words, relational databases are overkill for data that can be effectively used as key-value pairs and underkill for data that needs more context. Overkill costs you scalability; underkill costs you performance."