Forgot your password?

Want to read Slashdot from your mobile device? Point it at and keep reading!


Building Apps In Swift With Storyboards 69

Posted by samzenpus
from the build-it-better dept.
Nerval's Lobster writes Apple touts the Swift programming language as easy to use, thanks in large part to features such as Interface Builder, a visual designer provided in Xcode that allows a developer to visually design storyboards. In theory, this simplifies the process of designing both screens and the connections between screens, as it needs no code and offers an easy-to-read visual map of an app's navigation. But is Swift really so easy (or at least as easy as anything else in a developer's workflow)? This new walkthrough of Interface Builder (via Dice) shows that it's indeed simple to build an app with these custom tools... so long as the app itself is simple. Development novices who were hoping that Apple had created a way to build complex apps with a limited amount of actual coding might have to spend a bit more time learning the basics before embarking on the big project of their dreams.
Open Source

How To Find the Right Open Source Project To Get Involved With 57

Posted by samzenpus
from the get-going dept.
An anonymous reader writes Writing on, Matt Micene shares his thoughts on getting started with an open source project. "I came back from OSCON this year with a new fire to contribute to an open source project. I've been involved in open source for years, but lately I've been more of an enthusiast-evangelist than a hands-on-contributor to an open source community. So, I started some thinking about what to do next. When I was involved in projects before, it was due to a clear progression from user to forum guru to contributor. It's a great path to take but what do you do if you just want to jump into something?" Matt goes on to lay out several steps to help new contributors get started.

Ask Slashdot: Software Issue Tracking Transparency - Good Or Bad? 158

Posted by samzenpus
from the to-show-them-or-not-to-show-them dept.
First time accepted submitter Mike Sheen writes I'm the lead developer for an Australian ERP software outfit. For the last 10 years or so we've been using Bugzilla as our issue tracking system. I made this publicly available to the degree than anyone could search and view bugs. Our software is designed to be extensible and as such we have a number of 3rd party developers making customization and integrating with our core product.

We've been pumping out builds and publishing them as "Development Stream (Experimental / Unstable" and "Release Stream (Stable)", and this is visible on our support site to all. We had been also providing a link next to each build with the text showing the number of bugs fixed and the number of enhancements introduced, and the URL would take them to the Bugzilla list of issues for that milestone which were of type bug or enhancement.

This had been appreciated by our support and developer community, as they can readily see what issues are addressed and what new features have been introduced. Prior to us exposing our Bugzilla database publicly we produced a sanitized list of changes — which was time consuming to produce and I decided was unnecessary given we could just expose the "truth" with simple links to the Bugzilla search related to that milestone.

The sales and marketing team didn't like this. Their argument is that competitors use this against us to paint us as producers of buggy software. I argue that transparency is good, and beneficial — and whilst our competitors don't publish such information — but if we were to follow our competitors practices we simply follow them in the race to the bottom in terms of software quality and opaqueness.

In my opinion, transparency of software issues provides:

Identification of which release or build a certain issue is fixed.
Recognition that we are actively developing the software.
Incentive to improve quality controls as our "dirty laundry" is on display.
Information critical to 3rd party developers.
A projection of integrity and honesty.

I've yielded to the sales and marketing demands such that we no longer display the links next to each build for fixes and enhancements, and now publish "Development Stream (Experimental / Unstable" as simply "Development Stream") but I know what is coming next — a request to no longer make our Bugzilla database publicly accessible. I still have the Bugzilla database publicly exposed, but there is now only no longer the "click this link to see what we did in this build".

A compromise may be to make the Bugzilla database only visible to vetted resellers and developers — but I'm resistant to making a closed "exclusive" culture. I value transparency and recognize the benefits. The sales team are insistent that exposing such detail is a bad thing for sales.

I know by posting in a community like Slashdot that I'm going to get a lot of support for my views, but I'm also interested in what people think about the viewpoint that such transparency could be bad thing.

Microsoft Co-opts Ice Bucket Challenge Idea To Promote Coding In Latin America 96

Posted by Soulskill
from the i-challenge-all-of-you dept.
theodp writes: Microsoft is aiming to offer free programming courses to over a million young Latin Americans through its Yo Puedo Programar and Eu Posso Programar initiatives ("I Can Program"). People between the ages of 12 and 25 will be able to sign up for the free online courses "One Hour Coding" and "Learning to Program," which will be offered in conjunction with Colombia's Coding Week (Oct. 6-10). The online courses will also be available in Argentina, Brazil, Chile, Ecuador, Mexico, Peru and Puerto Rico. "One Hour Coding" (aka Hour of Code in the U.S.) is a short introductory course in which participants will learn how the technology works and how to create applications, and it offers "a playful immersion in the computer sciences," Microsoft said in a statement. In the virtual, 12-session "Learning to Program" course, students will discover that "technical complexity in application development tools is a myth and that everyone can do it," the statement added. Taking a page from the ALS Ice Bucket Challenge its execs embraced, Microsoft is encouraging students to complete the Hour of Code and challenge four other friends to do the same (Google Translate).

Ask Slashdot: Swift Or Objective-C As New iOS Developer's 1st Language? 314

Posted by timothy
from the two-roads-diverge-but-do-they-loop dept.
macs4all (973270) writes "I am an experienced C and Assembler Embedded Developer who is contemplating for the first time beginning an iOS App Project. Although I am well-versed in C, I have thus-far avoided C++, C# and Java, and have only briefly dabbled in Obj-C. Now that there are two possibilities for doing iOS Development, which would you suggest that I learn, at least at first? And is Swift even far-enough along to use as the basis for an entire app's development? My goal is the fastest and easiest way to market for this project; not to start a career as a mobile developer. Another thing that might influence the decision: If/when I decide to port my iOS App to Android (and/or Windows Phone), would either of the above be an easier port; or are, for example, Dalvick and the Android APIs different enough from Swift/Obj-C and CocoaTouch that any 'port' is essentially a re-write?"

Rosetta Code Study Weighs In On the Programming Language Debate 165

Posted by Soulskill
from the fresh-ammunition dept.
An anonymous reader writes: Rosetta Code is a popular resource for programming language enthusiasts to learn from each other, thanks to its vast collection of idiomatic solutions to clearly defined tasks in many different programming languages. The Rosetta Code wiki is now linking to a new study that compares programming language features based on the programs available in Rosetta Code. The study targets the languages C, C#, F#, Go, Haskell, Java, Python, and Ruby on features such as succinctness and performance. It reveals, among other things, that: "functional and scripting languages are more concise than procedural and object-oriented languages; C is hard to beat when it comes to raw speed on large inputs, but performance differences over inputs of moderate size are less pronounced; compiled strongly-typed languages, where more defects can be caught at compile time, are less prone to runtime failures than interpreted or weakly-typed languages."

Ask Slashdot: Finding a Job After Completing Computer Science Ph.D? 471

Posted by timothy
from the I'm-a-people-person-dammit dept.
An anonymous reader writes I recently completed my PhD in computer science and hit the job market. I did not think I would have difficulty finding a job esp. with a PhD in computer science but I have had no luck so far in the four months I have been looking. Online resume submittals get no response and there is no way to contact anybody. When I do manage to get a technical interview, it is either 'not a good match' after I do the interviews or get rejected after an overly technical question like listing all the container classes in STL from the top of my head. I had worked as a C++ software developer before my PhD but in the past 6 years, software development landscape has changed quite a bit. What am I doing wrong? Has software development changed so much in the last 6 years I was in school or is my job hunting strategy completely wrong? (The PhD was on a very technical topic that has very little practical application and so working on it does not seem to count as experience.)

The Site That Teaches You To Code Well Enough To Get a Job 131

Posted by timothy
from the tab-a-slot-b-memory-array-structure-q dept. writes Wanna be a programmer? Klint Finley reports that software developer Katrina Owen has created a site called where students can learn to craft code that's both clear and efficient and get a lot of feedback on what they're doing right and what they're doing wrong. Exercism is updated every day with programming exercises in a variety of different languages. First, you download these exercises using a special software client, and once you've completed one, you upload it back to the site, where other coders from around the world will give you feedback. Then you can take what you've learned and try the exercise again. The idea was to have students not only complete the exercises, but get feedback. now has over 6,000 users who have submitted code or comments, and hundreds of volunteers submit new exercises or translate existing ones into new programming languages. But even Owen admits that the site is a bit lacking in the usability department. "It's hard to tell what it is just by looking at it," she says. "It's remarkable to me that people have figured out how to use it."

'Reactive' Development Turns 2.0 101

Posted by timothy
from the off-with-their-oh-wait-that's-reactionary dept.
electronic convict writes First there was "agile" development. Now there's a new software movement—called 'reactive' development—that sets out principles for building resilient and failure-tolerant applications for cloud, mobile, multicore and Web-scale systems. ReadWrite's Matt Asay sat down with Jonas Bonér, the author of the Reactive Manifesto (just released in version 2.0), for a discussion of what, exactly, the reactive movement aims to fix in software development and how we get there from here.

Ask Slashdot: How To Avoid Becoming a Complacent Software Developer? 275

Posted by Soulskill
from the become-a-complacent-manager-instead dept.
An anonymous reader writes: Next year will be the start of my 10th year as a software developer. For the last nice years I've worked for a variety of companies, large and small, on projects of varying sizes. During my career, I have noticed that many of the older software developers are burnt out. They would rather do their 9-5, get paid, and go home. They have little, if any, passion left, and I constantly wonder how they became this way. This contradicts my way of thinking; I consider myself to have some level of passion for what I do, and I enjoy going home knowing I made some kind of difference.

Needless to say, I think I am starting to see the effects of complacency. In my current job, I have a development manager who is difficult to deal with on a technical level. He possesses little technical knowledge of basic JavaEE concepts, nor has kept up on any programming in the last 10 years. There is a push from the upper echelon of the business to develop a new, more scalable system, but they don't realize that my manager is the bottleneck. Our team is constantly trying to get him to agree on software industry standards/best practices, but he doesn't get it and often times won't budge. I'm starting to feel the effects of becoming complacent. What is your advice?

A Beginner's Guide To Programming With Swift 72

Posted by timothy
from the how-swift-is-it? dept.
Nerval's Lobster (2598977) writes Earlier this year, Apple executives unveiled Swift, which is meant to eventually replace Objective-C as the programming language of choice for Macs and iOS devices. Now that iOS 8's out, a lot of developers who build apps for Apple's platforms will likely give Swift a more intensive look. While Apple boasts that Swift makes programming easy, it'll take some time to learn how the language works. A new walkthrough by developer David Bolton shows how to build a very simple app in Swift, complete with project files (hosted on SourceForge) so you can follow along. A key takeaway: while some Swift features do make programming easier, there's definitely a learning curve here.

Ask Slashdot: Have You Experienced Fear Driven Development? 232

Posted by Soulskill
from the sunk-cost-fallacy-is-a-thing dept.
nerdyalien writes: A few years back, I worked for a large-scale web development project in southeast Asia. Despite formally adopting Agile/Scrum, development was driven based on fear imposed by managers. Scott Hanselman defines Fear-Driven-Development as having three parts. 1) Organizational fear has "worried about making mistakes, breaking the build, or causing bugs that the organization increases focus on making paper, creating excessive process, and effectively standing in the way of writing code." 2) There's also fear of changing code, which comes from a complex, poorly-understood, or unmaintainable codebase. 3) The most common one is fear of losing your job, which can lead to developers checking in barely-functioning code and managers committing to a death march rather than admit failure. My project ran four times its initial estimation, and included horrendous 18-hour/day, 6 day/week crunches with pizza dinners. Is FDD here to stay?
Data Storage

Micron Releases 16nm-Process SSDs With Dynamic Flash Programming 66

Posted by Soulskill
from the march-of-progress dept.
Lucas123 writes: Micron's newest client flash drive line, the M600, uses its first 16nm process technology and dynamic write acceleration firmware that allows the flash to be programmed as SLC or MLC instead of using overprovisioning or reserving a permanent pool of flash cache to accelerate writes. The ability to dynamically program the flash reduces power use and improves write performance as much as 2.8 times over models without the feature, according to Jon Tanguy, Micron's senior technical marketing engineer. The new lithography process technology also allowed Micron to reduce the price of the flash drive to 45 cents a gigabyte.
Open Source

Why Apple Should Open-Source Swift -- But Won't 183

Posted by Soulskill
from the programming-language-with-just-one-button dept.
snydeq writes: Faster innovation, better security, new markets — the case for opening Swift might be more compelling than Apple will admit, writes Peter Wayner. "In recent years, creators of programming languages have gone out of their way to get their code running on as many different computers as possible. This has meant open-sourcing their tools and doing everything they could to evangelize their work. Apple has never followed the same path as everyone else. The best course may be to open up Swift to everyone, but that doesn't mean Apple will. Nor should we assume that giving us something for free is in Apple's or (gasp) our best interests. The question of open-sourcing a language like Swift is trickier than it looks."

MIT's Cheetah Robot Runs Untethered 90

Posted by Soulskill
from the because-skynet-totally-needs-cheetahs-too dept.
An anonymous reader writes: It's easy to make a robot walk, but hard to keep it from falling over. We've seen a number of crazy robot prototypes, but they're usually tethered and/or stuck on a treadmill. Now, researchers from MIT have developed an algorithm that allows their giant robot cheetah to run around outdoors at up to 10mph. They expect the robot to eventually hit speeds of 30mph. "The key to the bounding algorithm is in programming each of the robot's legs to exert a certain amount of force in the split second during which it hits the ground, in order to maintain a given speed: In general, the faster the desired speed, the more force must be applied to propel the robot forward. ... Kim says that by adapting a force-based approach, the cheetah-bot is able to handle rougher terrain, such as bounding across a grassy field." The MIT cheetah-bot also runs on a custom electric motor, which makes it significantly quieter than gas-powered robots. "Our robot can be silent and as efficient as animals. The only things you hear are the feet hitting the ground."

KDevelop 4.7.0 Released 48

Posted by samzenpus
from the check-it-out dept.
KDE Community (3396057) writes "KDevelop team is proud to announce the final release of KDevelop 4.7.0. This release is special, as it marks the end of the KDE4 era for us. As such, KDevelop 4.7.0 comes with a long-term stability guarantee. The CMake support was improved and extended to ensure that all idioms needed for KF5 development are available. The unit test support UI was polished and several bugs fixed. In the same direction, some noteworthy issues with the QtHelp integration were addressed. KDevelop's PHP language support now handles namespaces better and can understand traits aliases. Furthermore, some first fruits of the Google summer of code projects are included in this release. These changes pave the path toward better support for cross compile toolchains. Feature-wise, KDevelop now officially supports the Bazaar (bzr) version control system. On the performance front, it was possible to greatly reduce the memory footprint when loading large projects with several thousand files in KDevelop. Additionally, the startup should now be much faster."

If We Can't Kill Cancer, Can We Control It? 140

Posted by Soulskill
from the thus-began-the-era-of-the-slave-tumors dept.
An anonymous reader sends this excerpt from The New Yorker: In April, [Dr. Eytan Stein] presented his findings to a packed auditorium at the annual meeting of the American Association for Cancer Research, in San Diego. It was the first public airing of the results of AG-221; patients with progressive [acute myelogenous leukemia] had never improved so quickly and definitively. ... The breakthrough is notable in part for the unconventional manner in which the drug attacks its target. There are many kinds of cancer, but treatments have typically combated them in one way only: by attempting to destroy the cancerous cells. Surgery aims to remove the entire growth from the body; chemotherapy drugs are toxic to the cancer cells; radiation generates toxic molecules that break up the cancer cells' DNA and proteins, causing their demise. A more recent approach, immunotherapy, co-opts the body's immune system into attacking and eradicating the tumor. The Agios drug, instead of killing the leukemic cells — immature blood cells gone haywire — coaxes them into maturing into functioning blood cells. Cancerous cells traditionally have been viewed as a lost cause, fit only for destruction. The emerging research on A.M.L. suggests that at least some cancer cells might be redeemable: they still carry their original programming and can be pressed back onto a pathway to health.
Wireless Networking

L.A. TV Stations Free Up Some Spectrum For Wireless Broadband 80

Posted by timothy
from the slightly-less-waste dept.
alphadogg (971356) writes An effort to free up some of the airwaves used by TV broadcasts and make them available for wireless broadband took a big step forward this week in the U.S. Two TV stations in Los Angeles, KLCS and KCET, have agreed to share a single frequency to deliver their programming freeing up a channel that can be auctioned off to wireless carriers next year. The change, which the Federal Communications Commission calls "repackaging," is possible because digital TV broadcasts don't need the full 6MHz of broadcast spectrum that was used for analog TV.

Unpopular Programming Languages That Are Still Lucrative 387

Posted by timothy
from the psst-I-got-a-line-on-some-hot-cobol dept.
Nerval's Lobster writes In theory, learning less-popular programming languages could end up paying off big—provided the programmers who pursue them play their proverbial cards right. And as with any good card game, there's a considerable element of chance involved: In order to land a great job, you need to become an expert in a language, which involves a considerable amount of work with no guarantee of a payoff. With that in mind, do you think it's worth learning R, Scala, Haskell, Clojure, or even COBOL (the lattermost is still in use among companies with decades-old infrastructure, and they reportedly have trouble filling jobs that rely on it)? Or is it better to devote your precious hours and memory to popular, much-used languages that have a lot of use out there?

If Machiavelli were a hacker, he'd have worked for the CSSG. -- Phil Lapsley