Czech37 writes Facebook may be the world's most well-known tech companies, but it's not renowned for being at the forefront of open source. In reality, they have over 200 open source projects on GitHub and they've recently partnered with Google, Dropbox, and Twitter (amongst others) to create the TODO group, an organization committed to furthering the open source cause. In an interview with Opensource.com, Facebook's James Pearce talks about the progress the company has made in rebooting their open source approach and what's on the horizon for the social media network.
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.
An anonymous reader writes Writing on Opensource.com, 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.
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.
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?"
New submitter RaDag writes: PostgreSQL outperformed MongoDB, the leading document database and NoSQL-only solution provider, on larger workloads than initial performance benchmarks. Performance benchmarks conducted by EnterpriseDB, which released the framework for public scrutiny on GitHub, showed PostgreSQL outperformed MongoDB in selecting, loading and inserting complex document data in key workloads involving 50 million records. This gives developers the freedom to combine structured and unstructured data in a single database with ACID compliance and relational capabilities.
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."
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.)
HughPickens.com writes Wanna be a programmer? Klint Finley reports that software developer Katrina Owen has created a site called Exercism.io 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. Exercism.io 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."
snydeq writes: Deep End's Paul Venezia follows up his call for splitting Linux distros in two by arguing that the new shape of the Linux server is thin, light, and fine-tuned to a single purpose. "Those of us who build and maintain large-scale Linux infrastructures would be happy to see a highly specific, highly stable mainstream distro that had no desktop package or dependency support whatsoever, so was not beholden to architectural changes made due to desktop package requirements. When you're rolling out a few hundred Linux VMs locally, in the cloud, or both, you won't manually log into them, much less need any type of graphical support. Frankly, you could lose the framebuffer too; it wouldn't matter unless you were running certain tests," Venezia writes. "It's only a matter of time before a Linux distribution that caters solely to these considerations becomes mainstream and is offered alongside more traditional distributions."
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?
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.
mrspoonsi writes Oracle founder Larry Ellison is stepping down as CEO. He will be replaced by two executives. Former Oracle presidents Safra Catz and Mark Hurd will be co-CEOs. Ellison will be the Executive Chairman of Oracle's Board, and the company's CTO. Oracle's shares are off by 3% on the news. "Larry has made it very clear that he wants to keep working full time and focus his energy on product engineering, technology development and strategy," said the Oracle Board's Presiding Director, Dr. Michael Boskin.
mikejuk writes with this excerpt: When Google Labs closed there was an outcry. How could an organization just pull the rug from under so many projects? At least Google announced what it was doing. Mozilla, it seems since there is no official record, just quietly tiptoes away — leaving the lights on since the Mozilla Labs Website is still accessible. It is accessible but when you start to explore the website you notice it is moribund with the last blog post being December 2013 with the penultimate one being September 2013. The fact that it is gone is confirmed by recent blog posts and by the redeployment of the people who used to run it. The projects that survived have been moved to their own websites. It isn't clear what has happened to the Hatchery -the incubator that invited new ideas from all and sundry. One of the big advantages of open source is the ease with which a project can be started. One of the big disadvantages of open source is the ease with which projects can be allowed to die — often without any clear cut time of death. It seems Mozilla applies this to groups and initiatives as much as projects. This isn't good. The same is true at companies that aren't open source centric, though, too, isn't it?