Mac developers embrace .NET with Visual Objective-C

Bellevue, Wash., April 1 – Declaring a “bright new day for our friends in Macintosh-Land,” Microsoft CEO Steve Ballmer today unveiled Visual Studio 2010 for Mac OS X, expected to be available this summer.

Speaking to a full crowd at the Meydenbauer Center, Ballmer reminded the audience that Microsoft is one of the oldest and most competitive ISVs for Apple’s Macintosh platform. The company’s Excel spreadsheet software first appeared for the Mac in 1985, he bellowed, two full years before Microsoft released a Windows version. “We never stopped loving the Mac,” he shouted, waving an iPhone. “Every day, our Windows 7 dev team is inspired by the great work being done by the visionaries in Cupertino.”

Standing in front of a giant poster of the new Visual Studio for Mac OS X, his voice hoarse with emotion, Ballmer screamed, “Now it’s time to give something back!”

The centerpiece of Visual Studio for Mac OS X is Visual Objective-C, a native implementation of Apple’s preferred object-oriented programming language, which is used on both Mac OS X and the iPhone SDK. According to Ballmer, Visual Objective-C will also appear in Visual Studio 2010 SP1 for Windows. Applications written in the Smalltalk-inspired language will require only a simple recompile to run on both Mac and Windows 7 systems, he said.

Playing to the cheering developers attending the software launch, Ballmer then showed Visual Basic for Mac OS X, another component of the Visual Studio for Mac OS X suite. “You asked for it, you got it!” he shrieked, before being buried by an avalanche of rose petals and hotel room keys tossed by ISVs and industry analysts.

Ballmer said that the Visual Studio for Mac OS X suite (expected to ship by Apple’s Worldwide Developer Conference, coming to San Francisco June 8–12) is designed to woo developers from Apple’s Xcode. “I know you love your Xcode,” he roared, “but I promise you’ll love your Visual Studio for Mac even more!”

On-stage demonstrations at the event included Macintosh integration with Visual Studio Team System; using Visual Studio with Apple’s iPhone SDK to build a voice-recognition spreadsheet application for iPhone and iPad; and porting BioShock 2 from Windows to Mac OS X 10.6 “Snow Leopard.” Ballmer sheepishly apologized for the tool chain’s lack of support for versions of Mac OS X prior to 10.5 “Leopard,” saying, “We’re only human, okay?”

As he was leaving the stage, Ballmer turned back. “Oh, just one more thing,” he cried—and then showed off the company’s full .NET Framework 4.0 for Mac OS X, available for free download from the Microsoft website. “We love you, Apple!” he whooped, bringing the event to a triumphant close.

The Latest News Briefs...

Microsoft released Windows Azure Home Edition for the growing number of consumers with enough desktops, laptops, netbooks, set-top boxes, game consoles and smartphones to create their own teraflop computing cloud. The software will be a direct upgrade from Windows Vista Ultimate with Windows Media Center...

Technology analyst firm Gartner has been named to a Gartner Magic Quadrant for its leadership in technology analysis. “This validates that Gartner has both the ability to execute and also the completeness of vision to lead in the technology analysis market,” said a spokesperson...

To the owner of the blue Toyota Camry in the back parking lot: Your headlights are on...

Intel demonstrated a new massively parallel version of its 64-bit Itanium processor, the first using Intel’s new 8nm Nebuchadnezzar architecture, which succeeds the Montecito, Montvale, Tukwila, Poulson and Kittson architectures. With 512 cores, peak interprocessor bandwidth of 12 TB/sec and peak memory bandwidth of 640 TB/sec, it is the fastest chip ever designed, and is literally decades ahead of anything you can do with an x86-64 processor. Analysts agree, however, that Nebuchadnezzar is not expected to gain many new customers for the slow-selling Itanium platform; nobody even showed up for the demo...

Social network giants Facebook and LinkedIn announced a merger. The new company, FacedInLinkBook, helps professionals share their most embarrassing college party videos with customers and prospective employers. Terms of the merger were not disclosed, pending the new company’s appearance in a Gartner Magic Quadrant...

Congratulation, your EMAIL ID have won 1,820,000 GBP. winning No: 10 20 25 41 44 46 with a bonus 6 for LOTTO 6/49 in the just concluded draw held in United Kingdom. please contact your Agent...

Big-brained computer engineers and software scientists from 154 countries attended the Rebooting Rebooting Summit, held in San Francisco last month. The purpose of the summit was to put our planet’s most brilliant minds onto the biggest unanswered question of our age: Why does it take so long for your computer to turn itself off when you select Shut Down from the Start menu?

Passive-Aggressive Design Patterns

Software engineers work with dozens of design patterns, but research shows that the most commonly encountered is the Passive-Aggressive Design Pattern. Known for its frustratingly obstructionist behavior, this design pattern can appear anywhere, but is most often found in applications deployed into unpleasant application servers or hostile data centers.

“This is one instance where some software definitely doesn’t play well with others,” said J. Marcus Wellington-Smythe IV, senior design pattern expert at the Institute for Software Behavioral Studies, speaking at a conference on April 1. “You code the module to execute a certain task or to carry out an operation using a specific algorithm, but instead you find that the module quietly just refuses to do its job.”

According to Wellington-Smythe, applications created using the Passive-Aggressive Design Pattern can be recognized by their many excuses about why things didn’t work out, as well as sincere assurances that things will be better next time. “You’ll see in the log that a buffer was full, or that there was a single-bit parity error. Perhaps a checksum didn’t match or network packets didn’t arrive. It doesn’t matter. There’s always something. The reality is that the routine doesn’t want to do its function, but won’t admit it to the CPU.”

In parallel-computing systems, the design pattern has been used to build multithreaded applications, with predictable results, says Wellington-Smythe. “Too often, a supervisor dispatches a thread to a core…and the thread simply never comes back, or returns much later without a good explanation and without the expected return code,” he said. “The supervisor might not even realize that the thread was simply stalling, just running out the clock.”

Wellington-Smythe pointed to a recent instance, where the Passive-Aggressive Design Pattern was used to architect a garbage collector for a virtual machine monitor. “Do you think that the garbage ever got collected? Yeah, right,” he moaned. “We had deallocated memory blocks everywhere, sitting around waiting to be picked up. You might call it learned helplessness, but all we heard from the collector was to trust it, it would get around to the task ‘soon.’ What a mess.”

Unfortunately, says Wellington-Smythe, once the Passive-Aggressive Design Pattern is in an application framework, no amount of refactoring will improve the software’s erratic behavior. “You can debug and profile and root-cause analyze until you’re blue in the face, but there’s no long-term cure,” he said. “It’s enough to drive you to abstraction.”

Taking software development on faith

TOPEKA, KANSAS, APRIL 1 – Speakers here at the Faith-Based Development Conference have demonstrated a software development methodology based on the concept that if you believe the code will work properly, it will work properly.

“All you have to do is believe, and we do this all the time,” said Ebenezer Scroom, CEO of Faith-Based Software Development Inc. (FBSDI), which sponsored the conference. “We turn the car key and believe that our engine will start… and it does. We push bread down into the toaster and believe that toast will pop out… and it does. We write thousand of lines of C# or Java, click the ‘Build’ button and believe the application will execute correctly the first time. In his heart of hearts, every developer believes this! The good news is that if you follow the principles of Faith-Based Development, your app will work the first time.”

Scroom cited anecdotal studies that demonstrate the power of Faith-Based Development to cut costs, shorten development cycles, improve software quality, and so on. “These results have been validated by industry analysts,” he said, “who were duly impressed when we hired them to author white papers and conduct webinars for FBSDI.”

There are four pillars of Faith-Based Development, explained Scroom, all of which can be easily implemented by tools sold by FBSDI. A project begins with Faith-Based Modeling, where architects use UML to document what Scroom calls “Faith Cases.”

Next, Faith-Based Coding relies on plug-in modules for Visual Studio Team System and Eclipse. “If you have faith that your syntax is right, then it’s going to be right,” he said.

The third phase is Faith-Based Testing. “This is perhaps the easiest part to learn.” Scroom said. “Developers are used to firing up their automated test suites, closing their eyes and praying. What we now know is that it’s the quality of the prayer, not the comprehensiveness of the test harness, that really matters.”

Finally, he said, it’s time for FBSDI’s Faith-Based Build and Deployment Services to bring together the final assemblies and push them out to the data center in one irrevocable operation.

“If you believe the software will be perfect the first time, there’s no reason to implement a phased rollout,” Scroom said. “If you have faith, you will succeed. If not… have I mentioned our professional services division?”

CLOUDBASIC opens computing paradigm to students, Mindy

DARTMOUTH, N.H., APRIL 1 — Hearkening back to the earliest days of computing education, a team of computer scientists have developed a special programming language to help students learn how to create mashups in the cloud. The language, CLOUDBASIC, was unveiled at Dartmouth College, home of the original version of BASIC.

“It’s been 47 years since John Kemeny and Thomas Kurtz showed off Dartmouth BASIC,” said Sara dePragma, a graduate student involved with the programming initiative as part of her Masters in Computer Education. “Heck, I wasn’t even born then. Come to think of it, neither were my parents. Sheesh!”

According to dePragma, the eight design principles of CLOUDBASIC are:

1. Be so easy that total losers like her roommate Mindy could use it.
2. Be a general-purpose programming language suitable to use as both a dessert topping and a floor wax.
3. Allow advanced features to be added for experts (which, duh, would make the language unusable by Mindy).
4. Be interactive using things called “dialog boxes.”
5. Provide clear and friendly error messages when a rogue program brings down the entire cloud environment.
6. Respond quickly for small programs, such as “Hello, Cloud.”
7. Not to require an understanding of the cloud’s hardware, unless the server is using an AMD processor.
8. Shield the user from the cloud, because the cloud is very big and ethereal.

Prof. Angus McMushroom, dePragma’s advisor, was quick to point out that the use of the GOTO statement within CLOUDBASIC was not his idea. “It’s not my idea,” he insisted. “I just know that nothing good’s going to come of it. I can just imagine that Ed Dijkstra’s turning in his grave. Just don’t blame me, okay?”

At the Dartmouth announcement, representatives of major cloud and industry players were present to pledge their support for the language:

• Microsoft released the first Community Technology Preview of CloudBasic#.NET for Windows Azure and the unannounced Visual Studio Team System Cloud Edition 2012.

• Sun announced that the Java Community Process would begin a JSR to develop with a language that’s similar to CloudBasic#.NET, except incompatible in a few subtle ways, and which would be implemented in NetBeans.

• The Eclipse Foundation is trying hard to come up with an acronym for their own CLOUDBASIC project, which it says will have OSGi extensions that will render it subtly incompatible with what Microsoft and Sun are doing.

• Apple has released iCLOUDBASIC, available in the iTunes App Store as a US$0.99 download.

• Google showed off the public beta of Google CLOUDBASIC Web Services, which are expected to remain in public beta for the next 20 years.

• Amazon.com invited SD Times readers to purchase the Kindle version of “CLOUDBASIC for Total Losers Like Mindy” at a 25% discount. Use the code MINDYISALOSER at checkout.

• The Free Software Foundation released an angry statement warning that it and the Software Freedom Law Center will sue any organization that doesn’t refer to the language as either GNU/CLOUDBASIC or as gcb.

“I’m so delighted to see everyone adopting CLOUDBASIC,” said Dartmouth’s dePragma. “Now, who’s up for helping me design its debugger for my Ph.D. dissertation? Mindy?”

This one's for you, Zephyr!

Letters! Letters from fans! They love me, as you can see in this e-mail that came in today. This is the best message that I've received this decade.

Hi,

We came across your "i.b. phoolen" blog and appreciate the informative content you have there.

We have just launched Zephyr which is a next generation Test Management System and wanted to introduce you to it by providing an exclusive look. Here's a live demo link – http://demo.yourzephyr.com – and there you'll be able to interact with the system anytime. We've loaded it with sample data to facilitate any product reviews. You'll find other assets (screenshots etc.) on the Media section of our main website – http://www.getzephyr.com.

Zephyr is a slick, feature rich and affordable Test Management System aimed at global SME, IT Departments and Testing Vendors. It brings a whole bunch of innovation in a space that has lacked it for the longest time. We'd like to draw your attention particularly to our customized Testing Desktops, real time Collaboration and Live Reporting via slick Dashboards as well as a host of Web 2.0 features.

We are test engineers ourselves and have designed and built Zephyr based on multiple years of real world experience. Your feedback or a mention on your blog would be very interesting to your readership while being a source of encouragement to us.

Thanks,
Sean Stewart
sean.stewart@getzephyr.com
http://www.getzephyr.com

The Software Tester’s Bill of Rights

Software testers are people too! Many of my best friends are software testers, and I can guarantee that they are people. In many countries, people have rights. Well, not everyone has rights. Airline travelers don’t have any rights, as we all know. Celebrities don’t have any rights. Neither do people who talk loudly on cell phones in restaurants or on the subway.

The reason why people talk loudly on cell phones is a design flaw, by the way. If the people who designed cell phones wanted to make friends, they’d program the phones to drop the call if the caller is being too noisy. Hey, rude people, mobile phones have sensitive microphones. You don’t have to shout!

Okay, we’ve established that airline travelers, celebrities and cell-phone abusers don’t have rights. What about the rest of us? We have rights, and that goes double for software testers. You know, testers take it in the shorts most of the time. The customer changed his mind after seeing the beta, and testers have to catch the variances. The architect messed up the caching algorithms? Testers have to account for nondeterministic behavior. The programmers spent too much time playing foosball? Test cycles get compressed. A line-of-business manager decided to release the software early? Test cycles get compressed. An end user found a bug? Testers get blamed for missing it.

Good people, it’s time we fight back with our very own Software Tester’s Bill of Rights. I know that you’re asking yourself, “What a brilliant idea. But who would write this Bill of Rights for us?” Fear not, gentle software tester. I.B. Phoolen is more than happy to draft this important document on your behalf. And now, without further ado, I present: The Software Tester’s Bill of Rights.

1. The Right to Own the Requirements

A tester’s job is to ensure that software meets requirements. Where do those requirements come from? Some from the customer. Some from the architect. There’s the problem.

Many of those requirements are obtuse, poorly written or plainly misguided. Those user stories — c’mon, folks. Don’t you have any imagination? Those performance and reliability metrics — you’ve got to be kidding, that throughput will never fly on a real-world network.

No wonder there are so many defects found by the test team, no wonder the overpaid programmers take so long to get the job done, no wonder the entire project is over budget.

Fortunately, we testers know better. We know what’s a good requirement, and what’s totally lame. Let us fine-tune the specs. Let us control the specs. If we disagree with a feature request, let us revise it or delete it.

If the test team owns the specs, we can guarantee that our tests will show that the application meets those specs on time, on budget, blah blah blah. Guess what? It’s not a bug, it’s a feature!

2. The Right to Kill the Project

That’s right. If the requirements are sufficiently moronic, or if we think the project is silly or necessary, we’re going to axe it. I.B. calls that “improving ROI.”

3. The Right to Choose Our Own Test Tools

Everyone talks about how developers are creative free spirits, who should be able to use the tool chain of their choice. If some programmers want to use Visual Studio or the IBM Software Platform, that’s fine with their managers. If Bob wants to run JBuilder, that’s fine too. If Sally wants to run Eclipse, nobody objects. If some show-offs eschew IDEs altogether to write the entire application with vi, lint, gcc and some duct tape, more power to them.

Meanwhile, C-level executive bozos want to standardize the quality assurance suites to embrace new flash-in-the-pan paradigms like “test automation” and “test driven development. They insist that testers use uniform tools and bug tracking applications, or — heaven help us — “ALM suites.”

Bullfeathers. Testers are just as creative as developers, as you can tell by reviewing my recent expense reports. We demand a generous budget so we can choose our own tools. As far as I’m concerned, every tester has an unalienable right to adopt the defect management system of his or her own choice, even if it’s Excel. If the CIO and VP of IT don’t like it, well, that’s their problem, bunky.

4. The Right to Employ Agile Methods

Preferably, those agile methods would be demonstrated by a perky aerobics instructor wearing a torn sweatshirt and leggings like Jennifer Beals in Flashdance.

5. The Right to Determine Release Schedules

I’ve had it up to here with test cycles being compressed due to boneheaded requirements, flawed architectures or nitwit coders who wouldn’t know an unchecked buffer if it bit them in the nose.

I don’t care if you’re rushing the product out to meet some contractual guarantee or the holiday shopping season. Under this Bill of Rights, any tester — any tester — can push back the release schedule at any time, with or without cause, and there ain’t nuthin’ you can do about it. If a line worker’s power to halt the production line improves the quality of Japanese cars, then by gum it works for software too.

6. The Right to Blame Microsoft for Everything

Self-evident.

7. The Right to Blame Open Source Software for Everything

Self-evident.

8. The Right to Redefine the IT Org Chart

In some organizations, development and test are peers. In others organizations, testers report into the development organization. Both of those models are flawed.

The only reason that companies hire architects and developers is to create applications for the test team to test.

Therefore, ipso facto, development is a subset of the test organization, and should be treated as such. That means that all developers work for the test organization. And, of course, all testers get paid more than developers, and get all the best parking spaces.

Take that, coding prima donnas. Who’s your daddy now?

9. The Right to Wear a Badge and Uniform

Heck, if we’re going to be the Quality Police, we might as well look the part. That’s especially important when doing Fuzz Testing.

10. The Right to a Whopping Pay Raise

If it’s good enough for politicians and CEOs, it’s good enough for software testers: We work hard, so we demand a bigger piece of the pie. Cash is good, but we’d like a generous serving of backdated stock options, too. Oh, while you’re up, could you grab my cell phone? I need to call Jennifer Beals. Thanks.

Retired software engineer I.B. Phoolen lives in Southern California, where he regularly frolics. He rarely updates his blog at ibphoolen.blogspot.com.