21–30 of 74 posts
Write something, anything! It doesn't even matter how good it is, just get something up and running. Then change it. Change it again. Repeat. Have you ever written anything before? Good. Then take the closest thing you have from your repository, strip out the code that doesn't apply and file it under the new name. There. You're already x% done. Now finish. I've tried many different approaches, but this one has worked…
Write something, anything! It doesn't even matter how good it is, just get something up and running. Then change it. Change it again. Repeat. Have you ever written anything before? Good. Then take the closest thing you have from your repository, strip out the code that doesn't apply and file it under the new name. There. You're already x% done. Now finish. I've tried many different approaches, but this one has worked…
No offense, but please don't use this template :)
[Next] would be a marketing website. Grab a theme off themeforest.net and work on a one page slideshow explaining your idea. Do this from a marketing perspective: sell it to your customers.
I find this is crucial because it forces you to refine your idea into a marketable idea. If you are taking 3 paragraphs to explain what your app does, what problem it solves, or why people should care, well your idea is probably not that great, much less marketable. What this also does is sell yourself on the idea. Once you've taken the time to craft out some great marketing copy, you begin to think "hey this does sound like a good idea!". You also have an easy way to get initial feedback from your network.
[Finally] after using your marketing site to get inner-circle feedback, you go after some customer development. Customers tend to need to see an actual working something though so it's probably best to code out and MVP. I'd start with modeling the data and then work out the core features and at long last, I get the joy of coding!
Write something, anything! It doesn't even matter how good it is, just get something up and running. Then change it. Change it again. Repeat. Have you ever written anything before? Good. Then take the closest thing you have from your repository, strip out the code that doesn't apply and file it under the new name. There. You're already x% done. Now finish. I've tried many different approaches, but this one has worked…
That way I still have the 'blank paper elephant' to stare at every now and then but at least not every project and I find that re-writing stuff it usually comes out much better on the next iteration.
It's like remodeling houses, every now and then it pays off to raze the thing to the ground and start over instead of adapting the house to a new occupant.
Once you have a design, turn the design into html
Once you have the html, start building out the functions in the design.
Write something, anything! It doesn't even matter how good it is, just get something up and running. Then change it. Change it again. Repeat. Have you ever written anything before? Good. Then take the closest thing you have from your repository, strip out the code that doesn't apply and file it under the new name. There. You're already x% done. Now finish. I've tried many different approaches, but this one has worked…
I have a template that does login, tabs, and layout.
I sketch in terms of "ghetto REST"; GET /foo, GET/POST /foo/new, GET /foo/1, GET/POST /foo/1/edit, POST /foo/1/delete. I write handlers before I write markup.
I write the same %ul#foos // - @foos.each do |foo| markup for every feature I start. Ditto the edit form.
Prune down, customize, work out page flows (which is easy once I have a base of things that works properly), pick a couple hotspots that want Ajax-y behavior (not because it's hard, but because whenever I start a project Ajax-y, I'm always unhappy with how brittle the result is).
I use Compass for the Blueprint/Sass style, but I don't waste too much time making things look good; my template gets me to about 80% of "competant" and 85-90% of "usable" and then, if I care, I spend money on a designer. I find knowing that I'm going to do this is liberating; means I don't waste a whole lot of time lining up pixels.
I never touch Photoshop. I can't mock up graphically. My brain just doesn't work that way. But then, I came to web dev from 10+ years of Unix commandline dev.
Sinatra, Haml, Blueprint, Sass, jQ. I have a template that does login, tabs, and layout. I sketch in terms of "ghetto REST"; GET /foo, GET/POST /foo/new, GET /foo/1, GET/POST /foo/1/edit, POST /foo/1/delete. I write handlers before I write markup. I write the same %ul#foos // - @foos.each do |foo| markup for every feature I start. Ditto the edit form. Prune down, customize, work out page flows (which is easy once I h…
Same here, and I'm beginning to think that that is slowly becoming a handicap rather than an advantage.
Personally, I dive right into the DB Schema. I use a modeling tool and just start with the basic relationships. For example, a User table and then as I think of features I think about how I will need to store them, how each entity relates to the other, etc. I'm a nut for normalization. At some point the schema is good enough to start coding some basic pages to login and do things. Of course, the schema never stays th…