January 30, 2008 by
ryan
Okay the title is a bit over the top :) Recently I was playing around with the vs settings after reading Scott Hanselman's article on black/white IDE colors and came up with this. I am still using the Monaco font and a lot of the same ideas, however, I toned down the colors slightly. Here are some screen shots of various languages in the .NET environment with the 'frickinsweet' settings file applied.
C# With the modified settings
VB.NET
HTML (well... in the context of ASP.NET)
F# (I really need to learn this language)
I have put the file for download frickinsweet.vssettings (10.73 kb)
You should get the Monaco or Envy Code R font for best results :)
To install the new settings file:
- Click tools
- Import and Export Settings
- Choose 'Import Selected Environment Settings' and click Next
- Backup current settings and continue
- Browse to the download location and click Next
- The Next screen you can confirm that you're overwriting just the fonts and color and click Finish
Please let me know what you think.
Update: Rob Conery has an alternative theme for Visual Studio available here.
Disclaimer: Download this at your own risk. Back up your current settings before adding the new one -- just to be safe.
January 27, 2008 by
ryan
An often overlooked area of Web Projects is quoting. Many developers
continually hone their programming and design abilities, however, few
value quoting ability as a necessary tool. Quotes that are inaccurate
can cost you; if you are too high, you are either ripping off your
client (apart from the ethical reasons it is also bad for you because
it may eliminate any future business and referrals) or you will not be
awarded the job. Here are some steps for better quoting.
#1 KNOW YOUR CUSTOMERS
You
will not sell anything that does not meet the customers needs -- no
matter how good the price is. Knowing your customer is the single most
important aspect of quoting. Sometimes clients will ask for something
that they don't really need. Instead of simply recognizing what they
are asking for, it is important to understand what they would like to
achieve. As developers or designers it is our job to educate the
client; to show them a more efficient way to accomplish their goal or
maybe even point out some things that were overlooked.
#2 KNOW YOUR ABILITIES
Know
exactly what you are capable of. Do not propose something that you can
not deliver. I realize that it is the nature of technology that it
will always be evolving and we will always be learning new things;
every project brings about new challenges. That being said, it is a
disservice to both you and your client if there is a lot you need to
learn before you can accomplish your proposed solution.
#3 BE THOROUGH
Your
proposal must be thorough. Obviously, being thorough does not mean
using technical jargon that would be above the clients head (remember
you want to educate, not confuse). Clearly present what you intend to
do and why it would benefit your prospective client. All the bases
must be covered all assumptions must be stated; do not leave any wiggle
room for assumptions because that can lead to a mess later (I know its
somewhat repetitive but I can't state it enough).
#4 PRESENT YOUR PROPOSAL PROFESSIONALLY (alliteration not intended)
Your
proposal will be seen as a reflection of your work. Make sure you
place the same kind of time and effort in to the flow and layout of the
proposal as you would any other design piece.
#5 ACCOUNT FOR ROAD BUMPS
According
to Murphy's Law, anything that can possibly go wrong, will go wrong.
Account for this in your time estimates. Take note of the areas where
there could be problems. Take some extra time while quoting to
research more about what the possible outcomes could be and create a
plan of action. This plan will give you a better idea of what
time-frame you're looking at.
#6 PRACTICE, PRACTICE, PRACTICE
Sometimes,
good quoting simply comes down to experience. The more jobs you have
quoted, the more data you have to work with to determine where you were
off and what areas you should focus more on. This may be common sense
but make sure you keep track of how many hours you quoted for a project
and how many actual hours it came out to be. Additionally, break down
the project into different sections. A more module approach will help
you determine where things went wrong.
Hopefully this will
be helpful to you no matter how experienced at quoting projects you
are. Please post your thoughts or any other quoting suggestions that
you may have. (originally written 3/17/2007)
January 27, 2008 by
ryan
For the past couple of years, I have been using a blog engine that I wrote from scratch (login system and everything). I knew there were a million of these already out there but it was something I was going to use as a learning experience (it was something I was using as a way to learn C#). It worked great and let me do everything I needed to, however, I have not updated the code in forever. My style of coding has obviously changed a lot since then. Instead of updating the code base to be more efficient and test-driven, I decided it was a good time to stop re-inventing the wheel. I'm now using Blog Engine.NET.
Over the next couple days, I'm going to be migrating some of the content over (some of it is just not worth it) and maybe make my own theme.