Results tagged “programming”

Everybody that's interested in F# has played around with some code, and it's amazing how much stuff you can put into a small space with the language, but at some point, you're probably going to get into a situation where you have more than one source file, yet you'd still like to stay functional.

So here's a suggested structure outline for those larger functional projects

A funny thing happened to me over the past two years of playing around with F#.

Programming became fun again.

The more I play with F# the more fun it gets. Take for instance this problem I was having last week.

I've spent the last ten years working on creating my own startup. I've read dozens of books, hung out with other people who wanted a startup online, joined clubs and associations, met with "experts" , etc. More to the point, I've actually built 5 startup ideas and tried them out.

I'm finally reaching the point where I'm starting to get traction -- I'm not Ramen-profitable, but some things are starting to "click" and I'm making enough money each month to cover server and domain expenses plus beer money. That's not Bill Gates-rich, but it sure beats a stick in the eye.

Now that I'm beginning to get traction, I'm also beginning to feel like I may never make it.

Why? Because there's a huge obstacle that I am not sure I can overcome on my own.

I have been playing around with F# for over a year now, and I really love it. I *think* I have most of it mastered, except maybe active patterns and workflows -- but I'm getting close to groking those. Recursion still makes me scratch my head for a bit, but I can recurse with the best of them once I get going.

What sucks is running into bugs -- not mine, but the compiler's. Here are two I ran into last week that's caused a lot of pain (and information about a possible third one)

I'm building a new startup -- it allows people to collect and share quotes from books and web articles. As you add each quote, you tag it. When people vote up or down your quote (or comment on it), the system trains itself to learn which tags each user likes. I may like quotes from American History. You may never want to see any quotes about politics. Over time, the system learns this and acts accordingly. That way you can have a broad range of subjects with a large user base and the app still has the feel of a private forum.

A while back, Paul Graham wrote a language called Arc. After he wrote it, he challenged other languages to create a simple set of web pages in as few tokens as possible. In Paul's philosophy, the fewer tokens a language has (or needs) the more robust it is. Therefore the more likely it is to last a hundred years

I've been thinking about Paul's assertion for over a year now. I've programmed in lots of languages -- to me they're just tools. Old friends. I can't say I am crazy about one language or another, no matter how many tokens it has.

As I and others pointed out, you can make a computer language do almost anything in as few tokens as you like as long as you've set up a DSL (Domain-Specific Language) for the problem domain.

Since I'm building my product almost from scratch, I thought I would take you through a quick tour of how you end up with powerful "languages" that have maximum expressiveness and minimum tokens, no matter what tools you are using. For this discussion, we'll stick to a (mostly) .NET stack, with some major modifications, but the stack is really not important.

"You've got to be very careful if you don't know where you are going, because you might not get there. " - Yogi Berra

Some things are so easy they're idiot-proof, but then along comes a better idiot to prove you wrong.

I was thinking about this today as I set up Visual Studio, F#, and Xunit

Since I thrashed around for about an hour and shouldn't have, I thought I would make an easy 1-2-3 cookbook for setting up F# and TDD.

As a proud Pre owner and hacker, I had a blast downloading the SDK this week. I'm planning a fun side-project, and the Pre looked like a cool platform.

And then I took a look at some of the limitations.

Preconditions:

• Many hours of monotonous coding ahead. Perhaps data cleaning, comment-checking, pixel-pushing, or code reviewing


• Desire to be entertained with lightly mind-engaging, upbeat music

Acceptance Criteria

• Songs must be rock-and-roll, ie, from the last 60 years


• Songs must feature prominent guitar work


• Songs must have been popular when released


• Songs must be recognizable to at least 40% of a randomly-selected audience


• Songs must generally be upbeat


• This must be a predefined, finite, readable list of songs that I own, not songs I want to buy, or songs I should be downloading

What would be the right way to code this? Given not a lot of time, I simply chose songs from "100 Greatest Guitar Solos" off of my hard drive. But I wondered: is there a better way? Not some quasi-internet radio station, a better way of picking songs with such fuzzy, yet describable criteria.

Last year I wrote an online agile project management system for a large corporation. I don't think you understand what's involved with a problem until you write the code for it and work with the users.

So in the spirit of sharing, I'd like to provide you with my list of features an online scrum tool would need to have.

I've been away from blogging for a while, working on a small project I have on the side. So my days have been mostly spent with getting up at 4, coding for 2 hours, working 10-11 hours, then coding for another 2 hours while I have supper and then off to bed.

It's been fun.

But reality sets in eventually, and as it turns out, people are interested in the application I have been writing. So I am going to have real users. This led me to make a decision I have been putting off for some time.

I have learned that you just can't go it alone -- startups are just too much work for one person to do. In addition to continuing to create the technology, somebody has to be as close to the users as possible. Somebody needs to be thinking long-term, and somebody needs to do all of the little stuff, like arrange server space, or teleconferencing tools.

So I decided to outsource. As part of that process, I ran into Martin Olivares.

Martin lives in Cordoba, Argentina. He's got lots of certifications and is familiar with the toolset I am using.

This should be a new experience! I'm interested to see how outsourcing can help a sole-proprietor create a business opportunity. Wish me luck.

So I'm writing a short ASP.NET program. And I've entered Grid Hell.

Lately when we talk about making sure our code is done well, we talk about various types of testing -- unit, system, stress, integration, performance, etc.

But it's not just testing. Everybody knows (or should know) what a code walkthrough is. Here are some other creatures in the quality closet. You may never use these, but it's good to have them handy and know what they are.

Stop the insanity!

Software engineering has been overrun with elephants.

I have been talking to some friends who are more into Agile with a big A than I am over the past couple of weeks. One of the topics was the purpose and use of modeling in developing software.

On one hand, people say its all emergent -- put a bunch of really smart people in a room with the Product Owner and fixed time-boxes and the conversation and code will follow along naturally. I don't think there is any denying that it's a true statement that software can emerge from shared conversations about problems.

On the other hand, there's the role of modeling in software development. Diagrams seem to help people understand and talk about things better, so couldn't they be part of a conversation as well?

I've been struggling with this, especially as a software and enterprise architect. Seems like people believe that modeling is part of the mindset of waterfall: that is, all the analysis happens, then all of the design, then all of the coding. In this worldview, modeling and modeling tools are just tools to control everything from the top down. It's a world where the "good" programmers control things for the "average" programmers. And when you model, you're not exactly doing one thing a time, are you? It's not like you're buying a story and going to make something of value happen for the Product Owner.

How to reconcile the good of modeling with the good of agile?

I'm an Agile Coach. That means I help teams adopt agile practices to make time-to-market shorter. I love agile with a little "a" But I have a confession to make: as much as I love the concepts in Agile and XP, the literature out there sucks. Here are the common faults that drive me nuts.

I've been consulting with a small Java team that's implementing SPRING and OSGI

I could tell you what they are doing but then I'd have to shoot you, so let's just say they're doing neat stuff.

I haven't poked around any of those two technologies in some time, and wow! SPRING looks like a great library, and OSGI (which I have had very little exposure) expands on SPRING in some powerful ways.

I wonder if there is something similar available in OCaml? Sort of a dynamically-available, real-time-bindable, functionally-based, language-oriented coding environment?

They pay me by the syllable, folks. I'm not sure, but I think I just made enough for a new pocket-protector. (grin)

Programming is not about programming.

I came to this realization after reviewing my XP and Agile books as part of an engagement for a large client. I must confess that each time I start on my XP books I have a hard time because I start laughing when I compare the books to reality. I think I finally can explain why.

It's not that I don't buy into Agile and XP -- heck, I was doing a lot of that stuff long before those books were ever published. It's just basic performance-based project management. I guess I always felt that in the theory and applied theory department, some of the XP and agile software authors either didn't know what they were doing or just making it up as they went along. I especially found funny their skewed view of "heavyweight" systems like RUP, CMM, CMMI, etc. The authors told horror stories about these other systems and then pointed out how much better their tactics were. After working with people who helped write the CMM and RUP, I found most of these guys don't want onerous paperwork systems -- these paperwork monstrosities are created by the practitioners, not the inventors. Then there was the whole cult of personality in the Agile/XP space that I found non-productive. To top it off, the XP books in particular felt more like political statements than serious tools for figuring out what software construction was all about. They were the kind of book to sell to frustrated programmers laboring under a huge paperwork beast and saying "We've got it all wrong!" Power to the people, man!

Understanding how Agile/XP ran off the rails will help you to understand why software development is not about developing software.

I am continually amazed at how a form of hero-worship exists in IT.

Just a few months ago, I was fortunate enough to apply for funding at Y-Combinator. It's like a boot camp for startups. It was formed in part by a guy named Paul Graham, who wrote a book called "Hackers and Painters"

I was turned on to the book by a employee for one of my clients. "You have to read this book. It's all about programming. Paul Graham is great!" I was told.

Lesson for the day -- always test your installs. If you don't, this could happen to you.

Shortly after releasing EVE Online: Trinity at 22:04 GMT on Wednesday, 5 December, we started receiving reports that the Classic to Premium graphics content upgrade was causing problems to players by deleting the file C:\boot.ini, which is a Windows system startup file. In some cases the computer was not able to recover on the next startup and would not start until the file had been fixed.

Oops.