| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful.
Albert Schweitzer
2012-10-26
Simple F# for Complex Problems; CQRS and Event Sourcing; Windows 8 Apps with HTML, CSS, and JavaScript
2012-10-22
Success is not the key to happiness.
Albert Schweitzer
2012-10-05
2012-10-04
Coders to Inherit the Earth? No!
Can we trust the code that increasingly runs our lives?
By Jane Wakefield - Technology Reporter
NASA Engineers weren't the only ones praying for a smooth landing when Curiosity landed on Mars.
Imagine how different the first pictures sent from the Mars Rover would have been if there had been a software failure.
Not to mention pretty hard to get someone along from the IT department to fix it.
One person breathing a sigh of relief when everything worked was Jack Chou, founder of software testing firm Coverity.
Software designed by his firm worked its way through two million lines of Mars Rover code, debugging and fixing problems as the software was being created.
"We were ecstatic that everything worked well," he told the BBC.
"One of the team did say that it found critical defects that could have caused problems if they hadn't been found," he said.
...from our mobile phones to the cars we drive, from the sites we shop and bank with, to medical devices that keep us healthy.It seems pretty obvious that complex spacecraft would be hugely reliant on software but these days so are many of the more mundane things that we take for granted
And just as software designed for space obviously needs to be bug free so too does code that binds us ever more closely to the connected world.
But, with an estimated 50-70% of software projects ending in failure, how can we put our trust in code?
Making mistakes
Improving software's somewhat tarnished reputation was one of the driving forces behind setting up Coverity in 2003, Mr Chou admits.
"To me as a young computer science graduate I felt it was a shame software was seen as unreliable," he said.
...says Jack Hughes. Along with three other PhD students and a professor at Stanford University, Mr Chou set out to create something different - software that could look for bugs as code was being written rather than wait until after the project was completed.One defect per 1,000 lines of code isn't a bad mistake rate
"Software ticks over a lot of different things. It is becoming autonomous and is controlling aspects of daily life that only a few years ago we couldn't imagine," he said.
On average the systems developed by Coverity detects one defect per 1,000 lines of code.
"If you think about 1,000 lines of code that is equivalent to 15 printed pages and if in an essay of that length you only had one error then that is pretty impressive."
But, he admits, there are always going to be below-average software developers.
"Even great developers make mistakes so the important thing is to make sure we put safety nets below so that the mistakes get caught," he added.
As we become ever more reliant on code, firms such as Coverity will become increasingly important.
Freelance Coders
But some believe a more radical overhaul of the way software is designed is also needed.
Topcoder is a growing community of more than 420,000 programmers, all of who compete in coding competitions to design software for both business and educational projects.
"Software projects become complex very quickly and they can go off the rails pretty quickly," said Topcoder founder Jack Hughes.
Jack Hughes hopes Topcoder can become an industry standard
"The software industry is a new one compared to say manufacturing. When you buy a product you expect it to work but software design just hasn't had that process behind it," he said.
By offering projects up to a community of programmers you get better results, much faster, he added.
"We do think that these models will become predominant in the industry."
With skilled programmers in great demand, tech firms are staring to follow what happens on sites such as Topcoder.
It ranks its programmers based on a range of criteria, gold-dust for potential employers.
"A Topcoder rating becomes an important element to people's CVs. Larger companies check this out," said Mr Hughes.
The community is starting to win some high-level clients, such as Medicare, the US government-run health programme. Topcoder recently won the contract to revamp its systems.
"They felt that they had to do something different and really wanted to try something that was a big departure from the usual way of doing things," said Mr Hughes.
Gone Golfing
Programmers also seems to love the Topcoder model, often because they can work when they want, ideal for a group of people not renowned for enjoying the nine to five routine.
"They can also work on multiple projects and spread their skills," said Mr Hughes.
Justin Gaspar runs a Topcoder team and says that it the most efficient place he has ever worked.
"With Topcoder you are basically paid to get something done rather than to sit somewhere for eight hours a day," he said.
It also results in far better code, he thinks.
"There is way more oversight and in terms of reviewing, code is looked at by two or three members. Peer review plays a big part."
Mr Gaspar admits that when he is heads down on a project it can mean a lot of late nights, but, on the flip side, when he isn't coding he has time off to play golf.
As the world becomes more connecting, so will our reliance on coders.
It has long been predicted that the geek will inherit the Earth.
Let's just hope that they have got enough sleep.
Original Article: BBC
2012-09-24
Some Questions Cannot Be Answered
It occurred to me that the perceived importance of a question is in direct inverse proportion to the ability to answer it.
This troubles me at the most fundamental level; and yet I know somewhere in my mind that it simply must be that way...anything else would be all the more wrong.
I can only wonder (as I don't feel particularly comforted by this knowledge): Is this what is meant by "acceptance"?
If so, why do I feel shortchanged in some way?
I suppose acceptance was billed as something entirely different to me.
2012-09-16
HTML5 Audio Player Code
HTML5 Custom Audio
I'm going to have to throw one of these HTML5 Custom Audio Players up on a site...nice.
2012-08-20
"The Best Programming Advice I Ever Got"
Rob Pike, now a Distinguished Engineer at Google, worked at Bell Labs as a member of the Unix Team and co-created Plan 9 and Inferno. He was central to the creation of the Go and Limbo programming languages. Rob shares an experience at Bell Labs that changed his approach to debugging.Be sure to check InformIT for a new article every Wednesday. See more advice from other programmers here.
Name:Rob PikeJob Experience:I worked at Bell Labs for many years. I was in the Computing Sciences Research Center, the (surprisingly small) lab that created Unix, although I was not there until after the Seventh Edition was released. Since 2002 I've been at Google, working on various pieces of infrastructure and infrastructure infrastructure.Most Notable Achievement:I'm probably best known for my books with Brian Kernighan, The Unix Programming Environment (still in print almost 30 years on!) and The Practice of Programming. The most widespread thing I've done was develop UTF-8 with Ken Thompson. But I've also done significant work in computer graphics, operating systems, software tools, and most recently helped develop the Go programming language.Most Frequently Used Programming Language:For too long to admit to here, C was my language of choice, but I have used many languages through my career. Nowadays almost everything I write is in Go; it is the most productive language I have ever used and has displaced C completely from my toolbox.Advice:A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all.When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct.
I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software."The Best Programming Advice I Ever Got" with Rob Pike | | InformIT.
When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct.
Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
2012-08-18
Can meditation make you smarter?
Wildmind Buddhist Meditation
Laura Schwecherl, Time: Most of us know that meditating is a great way to reduce stress. But meditative practice goes beyond taking a chill pill. Meditating is also associated with structural changes in the brain that help sharpen focus and improve memory and multitasking skills. But can this mind-body practice really help you get straight A's?
Smarty (Yoga) Pants — Why It Matters
It's not just tree huggers and ultra-yogis who meditate. In 2007, about 9% of American adults tried getting into their Zen zones at least once in the past year. Most people say they meditate to manage stress, but meditative practice affects …
Sent with Reeder
The Social Media Recruitment Survival Guide
Mashable!
At least 90% of recruiters are already using social media to find, source and connect with talented candidates. With Facebook at 901 million members and Twitter with 500 million accounts, an increasing number of employment-eligible people spend a good part of their day on one or more of these popular social platforms. It's easy to see why these networks are becoming key sources for employers and recruiters to find potential employees. When used effectively, social media can give an unprecedented boost to a company's recruiting capabilities.
Social media activity rose rapidly in recent years and the bigger platforms touch people's lives multiple times everyday, but using soci…
Continue reading...
More About: Facebook, Google, Jobs, Recruiting, Social Media, Twitter, features, job search series, mashable
Sent with Reeder
2012-08-17
2012-08-07
Managing the PATH Environment Variables On Mac OS X
How To Edit Your PATH Environment Variables On Mac OS X
The recommended way is by editing your .bash_profile file. This file is read and the commands in it executed by Bash every time you log in to the system. The best part is that this file is specific to your user so you won’t affect other users on the same system by changing it.
Step 1: Open up a Terminal window (this is in your Applications/Utilites folder by default)
Step 2: Enter the follow commands:
touch ~/.bash_profile; open ~/.bash_profileThis will open the .bash_profile file in Text Edit (the default text editor included on your system). The file allows you to customize the environment your user runs in.
Step 3: Add the following line to the end of the file adding whatever additional directory you want in your path:
export PATH="$HOME/.rbenv/bin:$PATH"That example would add ~/.rbenv to the PATH. The $PATH part is important as it appends the existing PATH to preserve it in the new value.
Step 4: Save the .bash_profile file and Quit (Command + Q) Text Edit.
Step 5: Force the .bash_profile to execute. This loads the values immediately without having to reboot. In your Terminal window, run the following command.
source ~/.bash_profileThat’s it! Now you know how to edit the PATH on your Mac OS X computer system. You can confirm the new path by opening a new Terminal windows and running:
echo $PATHYou should now see the values you want in your $PATH system variable...
Original Article
2012-08-06
Check out CSS
Check out this application on the App Store:
 | CSSPaul Hudson Category: Utilities Updated: Dec 16, 2011 |
iOS Applications |
2012-08-01
2012-07-31
Live SSO - Signing In in different langs.
http://msdn.microsoft.com/en-us/library/live/hh826543.aspx
Windows Live SSO Code
http://blogs.msdn.com/b/windowsappdev/archive/2012/06/26/best-practices-when-adding-single-sign-on-to-your-app-with-the-live-sdk.aspx
Subscribe to:
Posts (Atom)