HOWTO: The quick way to use Twitter Bootstrap with Genesis

May 13, 2013 by Leave a Comment

I love the Genesis Framework by Studiopress. And I love the Twitter Bootstrap Framework for creating “standard” web interfaces. There is so much that both the Genesis and Bootstrap frameworks get right when it comes to ease of use and consistency. Because I love them so much, I decided to start using them together to get great looking front-end layouts that Studiopress doesn’t provide out-of-box. I like having solid looking tables, buttons, and forms, so Bootstrap is a great way to get that easily and quickly.

Here’s the quick and dirty way to use Genesis and Bootstap together.

1. Download a custom package of Bootstrap

One of the main reasons that I use the Bootstrap framework on WordPress sites with Genesis is to get some of the sleek looking front-end look to buttons, tables, forms, etc. I don’t normally use the entire Bootstrap framework with Genesis, usually just tables and buttons, but if you want the entire thing you can do that too.

Go grab a custom package of Bootstrap here. First click the Toggle All button on the Choose Components heading. Then simply choose the following from the list:

  • Tables
  • Forms
  • Buttons
  • Icons

This will get us a good start. Next, click the Toggle All button on the Select jQuery Plugins. We don’t need any of these for this exercise. Scroll to the bottom and click Customize and Download. Next, unzip the file you just downloaded.

2. Move the Bootstrap files to your WordPress installation

I’m not going to go in depth on how to access your WordPress installation via FTP (you can find that elsewhere). Drill down to your Studiopress theme folder. In my case here at DevBurner, I use the eleven40 theme so I would go to:

/wp-content/themes/eleven40

Next, upload the entire bootstrap folder you just unzipped to the root of your theme directory.

3. Include the Bootstrap CSS file in your site’s header

I like to do this with the Genesis Simple Hooks plugin (if you don’t have it, install it from here or simply search for it in your WordPress installation via the Plugins > Add New). Once the plugin is activated, in your WordPress backend go to Genesis > Simple Hooks. In the hook for wp_head fill it in with this:

<link rel="stylesheet" type="text/css" href="/wp-content/themes/eleven40/bootstrap/css/bootstrap.min.css" />
<script src="/wp-content/themes/eleven40/bootstrap/js/bootstrap.min.js"></script>

Remember to replace the name of your theme folder with the one that you are using.

4. Now you are done, so test it out

Because of the little bit you did above you get some great stuff.

Nice looking tables by using the table CSS class for your tables.

<table class="table">
  <tr>
    <th>Title</th>
    <th>Description</th>
  </tr>
  <tr>
    <td>This is the title</td>
    <td>This is the description</td>
  </tr>
</table>

This markup creates this:

Title Description
This is the title This is the description

If you want to add a nice striped layout to your tables, just add the tabled-striped class to your table:

<table class="table table-striped">
  ...
</table>

You’ll get this:

Title Description
Great looking tables Are awesome
Great looking front-ends Are exciting for people to use
Great looking sites Are something people come back to again and again

You also get some great looking buttons by simply using the btn class on anchor links:

<a href="http://google.com" class="btn" >Go to Google</a>

The above yields:

Go to Google

You can also add some classes like btn btn-primary, btn btn-success, or btn btn-danger will give you:

Go to DevBurner

Go to Apple

Go to Microsoft

There is so much more you can do now with the power of the Genesis and Bootstrap frameworks combined. I highly suggest for you to check out the Bootstrap framework documentation if you want to utilize some of the great front-end enhancements it can bring to your website.

Filed Under: Development, Technology Tagged With: , ,

Anonymous MSFT developer admits Linux is faster than Windows →

May 12, 2013 by Leave a Comment

Well, if you’ve used Linux for any length of time and compared its speed to that of Windows, this was a no brainer. What’s damaging is that this Microsoft OS developer brings to light just why Linux is faster. Not only does it show that Microsoft is misguided and in trouble if they keep going down this road, but it alarms me that they don’t give a shit about their operating system.

You know, the operating system that millions of people pay for their businesses to run mission critical applications and mail servers on. The operating systems that Microsoft charges asinine amounts of money for.

I wish that Linux would become much more viable in the next few years, and that major software vendors start to switch to if. In other words; I’ll keep dreaming.

★ Link
Filed Under: Development, Technology Tagged With: , ,

Get Your Subtle Patterns at subtlepatterns.com →

May 5, 2013 by Leave a Comment

If you are looking for some amazing subtle backgrounds for your sites, apps, documents, even desktops, then I have to highly recommend checking out subtlepatterns.com.

I’m thinking about applying some of them to DevBurner and have been playing around with them on different development sites. Adds a nice touch to your design and free is always good.

★ Link
Filed Under: Development Tagged With: , , ,

BaBSE 9: Know Your Tools

August 31, 2012 by Leave a Comment

Being a good software developer means that you can create software solutions that help solve problems quickly. Being a software developer doesn’t mean that you know every little nook a cranny of a language or every design pattern on earth (although, this can help and is something I personally need to concentrate on), but it does mean that you know how to use tools to create solutions for people effectively.

There is a whole market (free and paid) for development tools that help developers get stuff done in their work lives. And of course, there is a multi-billion dollar app and software market that has been around for decades. These are all tools that help people create and get their jobs done. But is it really only about the tools that you use to develop or to get things done?

You are only as good as your tools

This idea of only being as good as the tools you use to make things is pretty right on. This can be a fine line though. Some people think that you need a super-mega tool to get things done (for instance a full blown SAP implementation for Enterprise Resource Planning) opposed to something that has just the right amount of features you need (where I work, this is an ERP system called JobBOSS).

I think that rather than saying that how good the tools you use dictate how good you are at programming, planning, writing, etc. it should be more along the lines of:

You are only as good as the tools you know

This notion says that it doesn’t matter exactly what tools you use to get things done, but that it’s more important that you know the tools inside in out. So, whether you are using a full blown IDE or a simple text editor to develop, it doesn’t really matter as long as you know the tool and can still develop solutions quickly and effectively.

While developing on Windows I use Visual Studio because it’s pretty much the only tool that I need (and can use) to make Windows and ASP.NET apps. There is a ton to learn about Visual Studio itself, but once you get past all the knobs and switches you can be incredibly fast and productive with it.

It doesn’t stop here

Being only as good as the tools you know isn’t just about software development; it works with productivity, writing, reporting applications, document creation software, etc., so this can apply to anyone that deals with any type of toolset in their work and life. As you get further and further into developing software and solutions you will find that it isn’t about the tools that you use, it’s about knowing what you need to get the job done and then finding and learning tools that support that. So, maybe it’s time to stop looking for tools to make you better, get better and then find and learn tools that support you.

Filed Under: Development Tagged With: , , ,

BaBSE 7: Perfect Planning Doesn’t Exist

August 24, 2012 by Leave a Comment

I’ve been “working” on a web app for sometime now and will use it as my “calling card” moving forward. It’s just something small and effective that I need to create to ship something into the world, to break the ice, and to create a platform to build off of.

The problem is that I plan too much, too often, and when I get stuck planning the application, I freeze and don’t do anything. But, it doesn’t have to be that way for technologists and software developers.

Big systems

When I was working for a large insurance company we had some intense project planning going on. Timelines, small project packets (200 pages isn’t small though), meetings, meetings, and more meetings. It felt like overkill, but, in reality was probably an important thing to do for the complexity and depth of what was going on with different pieces of software, not to mention we had to make sure that regulatory and certain legalities were taken care of. Some of these systems were 20/30 years old and we were integrating new stuff with them which added another portion of complexity.

This type of in depth planning is mostly needed for large systems (although, some of the meetings were a complete waste of time). But, even those these plans that are in a perfect little Gant charts, created with picture perfect white board sessions, and detailed in small project packets with code and comments aren’t perfect and sometimes completely fail.

Small systems

With smaller systems and apps we have the choice to not go into as much detail when we plan. We can get away with skipping complete plans and timelines and concentrate on smaller, more concise plans that actually mean something. Here are two awesome resources for planning software:

  1. Painless Function Specifications Series from Joel on Software

    If you want to do a little more in depth planning, this is the way to do it.

  2. Getting Real by 37signals

    If you want a “no-BS” approach to making quality software without the overhead of planning too much, this is the way to do it.

Here’s the hit

If you are planning large or small systems you can’t do it perfectly (even with the awesome resources above). You can get close to creating accurate plans, but it’s never perfect. So, instead of spending the time to create a plan that is “iron-clad”, spend less time making a passable plan and then start creating. When you hit a brick-wall with your plan or things don’t match up with your plan then change your plan.

What tends to happen, at least with this technologist, is that I plan some software (mockups, requirements, small functional spec, etc.) and when my actions start to go outside of the plans, I start to think that my plans are “wrong” and then scrap them. That’s not how it should work. We have to remember as technologists and developers that plans will change, especially for small or medium size systems and even more so when you don’t have any sort of hard requirements (like legal or regulatory).

So, rather than plan for perfection and think that you have failed when plans change, plan for change and understand that your systems will never be perfect even after the system has shipped.

Filed Under: Development Tagged With: , , , , ,

BaBSE 6: Knowing When to Say No

August 17, 2012 by 3 Comments

Solving problems with systems and software is a tough job. And it gets tougher when you have users dipping their phalanges in the system that you need and want to create for them.

Common things you will hear during the software development process from users are, “yeah, that’s great, but…” or “well, I thought it should work like…”. If you have been developing for any time at all then you are probably accustomed to this behavior.

Don’t hate the player, hate the game

It’s not the user’s fault that they want a billion different things in a new system. They simply want an awesome system to do their job and make their lives easier. But, there is a little term that called feature creep that destroys developers’ lives. This is the idea that as one new feature gets added to a new system, then ideas start flowing and other features are suggested and then “needed” by users.

This is the “game” of defining features for systems. You have to be good at this game to make sure that you don’t design a system that has a million functions, looks amazing on paper, and then will never be developed because it is too much work.

Brainstorming

It’s never a bad idea to sit around the table with some users and come up with a bunch of potential features for future systems. This allows everyone to work together and bring their different background and perspectives to light. This is a super important exercise in the software development process and shouldn’t be avoided because you are afraid of feature creep.

But, what tends to happen is that users (and developers) get this idea in their head that all of their good ideas will be put into reality. This is dangerous territory.

So, to make this game better, make sure that when you are brainstorming ideas for systems, that you and everyone else knows that this is a brain dump of ideas, nothing more, nothing less. Don’t say no to particular ideas in the process. Instead, come at it from the perspective that none of these ideas “are the system”. These ideas are just ideas.

Saying no

Saying no to particular features of a potential system is the most important part of developing a system that will actually work. I work in a team of 1 where I work and because of that I have to say “no” a lot. All ideas are great ideas until you look at the details and realize how much work they will actually take to implement.

I can’t remember the exact saying, but it basically goes like this: However long you as a developer thing something will take to create, convert it to the next time unit and multiply it by 2. So, if you think a feature will take 2 hours to implement, you should say that it will take 4 days.

The numbers don’t really matter. The point is that new, awesome features take time and resources to create. If you don’t have the time and resources, then you have to say no to things that aren’t “core” to the system. This can be a painful pill to swallow, especially in a corporate environment where sometimes saying “no” is not an option.

When to say no

So, when can you say no to something? My best advice on this is that the only real time that you can do this is when you have worked with users and stakeholders of the system and identified all of the “potential” features. With that raw information in front of you, you can pick the top 5 features that you have to implement for the system to be the system. Everything else is a no until those 5 features work awesomely well.

The number 5 isn’t necessarily a hard-and-fast rule. The idea is that you are taking a workload of development that by the end of it will produce something that is worth something to your users. Yeah, they may not have all of their amazing, whizz-bang features that they were hoping for, but they have something that is usable. Other features can come later.

So, you have to say no a lot, especially in the beginning of a project or if you are strapped with little resources (raises hand).

Here are some other really great posts/books on this topic. Just remember implementing features is all about what you can handle and get done. After a couple of years you become much more realistic when it comes to timelines and what you can handle as a technologist.

One last thing, if you didn’t make the connection, this saying “no” stuff isn’t just about software development. You can use the idea of creating boundaries and doing just the right amount of stuff when it comes to productivity as well.

Filed Under: Development Tagged With: , , , ,

BaBSE 5: Learn to Learn

August 10, 2012 by Leave a Comment

Becoming a Better Software Engineer (BaBSE) is a series that I started at the beginning of the year. Every Friday I will write about something I’ve learned in the technology field (and mostly likely in the field of life). This helps further my skills as well as any other fledgling technologist or software developer that wants to learn. So, let’s get on with it, shall we?

There are two things that will always stay the same when it comes to software development (and anything in the technology industry in general) are:

  1. Things will always change.
  2. If you don’t accept the change and keep up with it, you will be left in the dust.

When you know these two things about technology it makes thing a heck of a lot easier, that is, if you are willing and able to learn quickly and efficiently. It also doesn’t hurt to actually love to learn new things.

Know your learning style

Some people need to learn new things by doing them while others can learn just by reading something or someone telling them how to do something. It’s important for you to know which learning style works the best for you because as a software developer you are going to be doing a lot learning quickly.

For me, I learn best with a mixture of tutorials, books, and hands on work. I find that I get a vague understanding of something by reading and then solidify it with doing physical work. Over the past year I have learned almost everything technology related this way and it’s worked well.

You better love to learn

One of the main reasons that I got into information technology and development was because I loved learning new things. This field encourages me to keep learning new and better ways to do something because information is always changing.

One thing that you should know about the technology industry is that if you don’t actually love to learn, the chances of you doing well and actually liking what you do are pretty slim. Like I said before, you have to be able to learn because this industry is constantly changing; if you can’t stand to change or learn something new, you are at a major disadvantage and will most likely end up bitter about your job.

No, it really doesn’t ever end

It’s funny when I start this though, “well, now that I got learning ‘x’ out of the way it’s going to be easier to do…”. That feeling lasts for about an hour until I realize that learning ‘x’ has opened me up to an entirely other set of things to learn as well as all the exceptions. Learning about software development doesn’t really ever end.

There were always be a new version of something, a new framework to try, new operating systems and languages to learn; always something. Being able to know your learning style and loving to learn will make this easier.

Learn to learn more than tech

The number one reason that this site isn’t totally about programming and technology is that alone does not make you a good technologist. Being good at anything doesn’t involve only that one thing; talent builds off of and around other expertise. When I wrote about becoming a technologist, I made the claim that there are 7 things that you will have to be good at to be a good technologist. Programming is just one of them.

Just as being a good human is made up of a bunch of stuff, so is being good at anything else. Learning how to communicate effectively (so many tech people can’t), understanding entrepreneurship and business, as well as learning about becoming and staying productive, will benefit you greatly as a software engineer.

So, rather than get out of school, learn for a couple of years about a job that you took and calling it “good”, we as technologists have to keep learning everyday to stay ahead of the curve and to make our jobs more enjoyable and productive.

Filed Under: Development Tagged With: , , , ,

Ubiquity is a Feature

February 20, 2012 by Leave a Comment

Are you a Mac fanboy? A Windows “Power User”? Do you scoff at how “zealots” tote around their iThings and disregard anything and everything else as being a viable option? If so and you are a developer or creator of software, you may want to take a step back and consider including the “ubiquity feature” in your apps.

Cross platform app development is here to stay. So, rather than disregard it, use it as a feature of your software.

Other OSes exist

I have had quite the transition from Windows user, to Linux user, to Windows “power user”, to Mac, to anything under the sun user. What I still find hard to believe is that some developers only offer their software for certain “platforms”, even with the availability and growing power of creating a web and mobile applications. The fact is that there are other OSes in the world.

Many Mac aficionado tend to think that there are only Macs in this world. As Apple has been making a killing lately with iOS and even with OS X, we have to remember that the majority of people on earth run Windows. This of course will probably change as Microsoft has been digging their own grave for well over ten years now because of their stagnation, but the fact remains that there are many OSes and platforms out there to support.

We should plan for them

There may be a number of good reasons why developers create software for a certain platform or another, but if they are creating frontward facing services for end-users, it seems like a real misstep for them to not use web and  HTML 5 technologies to make their apps available to all.

Developers (especially fledgling ones like myself) should plan for this. Rather than develop apps for a certain platform, we should be opening them up to anyone and everyone. We are limiting ourselves because of lack of experience in a platform or just plain “zealotness”. At the very least, developers should offer robust APIs so that other developers that have an interest in a certain platform can interface with their software.

Cases and points

One good example of a software company that is doing this right (other than the whole not charging anything part) is 6Wunderkinder. They used Appcelerator’s Titanium products to make Wunderlist available online, for Mac, Windows, Android, and iOS in record time. And for the most part, everything works without a hitch. We can argue whether Wunderlist has the features that one needs for tracking their todos, but what we can all agree on is that in this case Wunderkinder has made ubiquity a feature.

Twitter is a great example of an app and service that made a great API for developers. This can be argued to be one of the main reasons that popularity for Twitter grew so quickly.

Another good example of this is the webapp Toodledo. It may not be the most grand, exciting, or pretty app, but Jake at Toodledo has done a hell of a job of making his app ubiquitous as well as created a great API so third party developers can create applications that work with it. Yet another is the new app Asana (one that a good friend has adopted over an app that can’t be used cross platform) which has a very responsive web interface. The mobile app is sort of lacking, but new additions are made consistently.

Other apps like OmniFocus (or anything from the OmniGroup), Microsoft Office (although it’s getting better) and others are limiting themselves by not giving users the ubiquity feature or decent APIs for third party developers. These developers may scoff and say things like, “well, you can’t get real work done on a Mac anyways (yeah, that’s you M$),” or “we want to only cater to the Mac platform,” but the fact is that the OS is becoming less and less important with the availability of the web and the growth in the power of web and mobile technologies.

Conclusion

I can’t say that apps that are only for iOS or Mac or Windows won’t do well (because apps that are only for those platforms continue to do well). What I can say is that ubiquity is a feature, that cross platform app development is important, and should be added to any new application that is being released. Whether the apps are ported to a specific platforms, available on the web, or have an API that other developers can access, developers need to pay attention and make their apps accessible from anywhere at anytime.

Filed Under: Development Tagged With: , , ,

Becoming a Better Software Engineer 2: On Learning Language(s)

October 31, 2011 by 1 Comment

“What programming language should I learn?”

Ahh… the common tome that I have heard and said myself through the several years gearing up to be a software engineer. I’ve come to realize that the reason why new devs ask this question so often is that believe the language they choose will make or break their career. This is sort of true, but more of a fallacy than not.

First about me

The first thing I learned when I was young was some HTML and CSS so I could create websites. I remember starting a Star Wars website when I was 12 or 13. It had a Galaxy background and everything. I wouldn’t necessarily call HTML or CSS “programming languages” (‘markup’ fits), but it did introduce me to the idea that there were syntaxes that you could use to manipulate data and the presentation of it in some way.

I didn’t really start programming until I messed around with PHP around the age of 18. I wrote a few custom things like sign-up forms and learned how to pull data out of a MySQL database, but that was the extent of it.

I really started programming when I entered college and learned VB, C# (both with .NET), C++, bash scripting, Java, JavaScript, and XML. This is when I actually wrote programs that compiled down and could be run on a computer. So, I would say that I have been programming “for real” for about 4 years.

Now about you

So, what language(s) should you learn? As many as you want.

I know, I know. Not the answer you were looking for, but it’s true. Learning programming languages to a developer is like learning spoken languages to a world traveler. There is a “core set” that you need to know to get things done now, but there are so many more interesting ones that you can use later in your travels.

So, here is a basic plan that can probably work for just about anyone.

1. Learn some “standard languages” first

First, learn at least one, if not a few, “standard languages”. By this I mean languages like C, C++, Java, or C#. All of these accept for C# are cross-platform and are (at the time of this writing) in super high demand. You really can’t go wrong with learning any or all of these languages. Plus there is a ton of information about all of them on the web.

2. Learn a “web” language

Since the web is the new cross-platform platform, you should invest some serious time in learning a web language or two as well as some frameworks. If you don’t know HTML or CSS you better get on those. After that you can learn some web languages like PHP, Ruby (for Ruby on Rails), C# and .NET libraries, Java and web libraries, etc. These are by no means all the “web” languages that are available to learn, but once again, if you learn these few you will definitely be applying yourself in areas that are marketable.

And of course you should learn JavaScript as well as a good JavaScript wrapper like jQuery.

3. Dive in

After you have garnered a nice set of “standard languages” under you belt, it’s time to dive into anything and everything you little hacker heart desires. Learn Scala. Grok F#. Write some Perl then try to understand it after you write it. Get into any language that you think is cool and then get passionate about them. There will always be new and “better” languages that enter the development scene. You will never get bored as a developer, nor will you ever learn and know everything.

Wrap-up

You may be thinking,

“I wanted to know exactly which programming languages to learn to be a relevant developer. Thanks for nothing”

Well, if you are looking for a “magic-bullet” type of programming language to be the absolute best for your first language to learn, then stop it. It doesn’t exist. There are definitely some great languages to learn off-the-bat that get you started programming, but the reality of developing software for an extended period of time is that you will have to learn several languages and keep learning them throughout your career.

Some sites you should check out

Learn C++: http://www.cplusplus.com/doc/tutorial/

Learn C: http://www.cprogramming.com/

Learn C#: http://msdn.microsoft.com/en-us/vcsharp/dd919145.aspx

Learn Java: http://download.oracle.com/javase/tutorial/reallybigindex.html

Learn Ruby: http://www.ruby-lang.org/en/documentation/quickstart/

Learn PHP: http://devzone.zend.com/article/627

Learn JavaScript: http://www.learn-javascript-tutorial.com/

Learn HTML: http://www.html.net/tutorials/html/

Learn CSS: http://www.html.net/tutorials/css/

Filed Under: Development Tagged With: ,

Becoming a Better Software Engineer 1 of 1000: Knowing When You Don’t Know

October 28, 2011 by Leave a Comment

This is the first of many BaBSE posts to come. Enjoy!

One of the hardest things that I have had to do since I have entered the real world of software development is admitting that I have know idea what I am doing at times. This is most evident when it comes to specific technologies, business processes, and even sometimes algorithm logic.

It hurts. But have no fear.

Knowing when you don’t know something can produce some awesome things in your development world. I can think of two that you will experience immediately when you identify and admit you don’t know something:

  1. A greatly reduced sense of stress
  2. The opportunity to learn from someone who actually does know something

Let’s take a closer look at these two experiences.

Reduced stress

Trying to be something your not is stressful. Trying to learn a development skill quickly to protect your “credibility” while others around you know it and use it all the time is not only a wast of time, it is nerve racking.

Some fledgling software developers (this one included) have a hard time admitting that they can’t figure something out. Because of this they (they as in I) will spend a crap-ton of time Googling their way to an answer when someone around the corner knows exactly what you are trying to accomplish and can help you in a moment’s notice.

It’s one thing to struggle with something by yourself and work your way through it. Like struggling with a piece of code or algorithm until you understand what you are doing. This is a learning experience. But, not getting help from another developer (or even supporting team member) with something that they are awesome at doing is not smart. You don’t learn any valuable skill from struggling at Googling, but you sure as hell can learn some things from being taught by another software developer that knows knows what they are doing.

So, stop trying to be a know-it-all and learn from someone with experience.

Learning something new

The best way to reduce your stress in not knowing something is learning what you don’t know from a developer with experience in what you are trying to do.

For instance, I knew how to develop in C# and sort of blindly felt my way through developing some ASP.NET Windows Forms applications. After learning a little about Ruby on Rails I decided to try out ASP.NET MVC 2/3 and make it the standard way that I developed small web apps for work going forward.

What I didn’t know is that deploying an MVC application to an IIS server was a completely different process than deploying an ASP.NET application. It was so different that I almost gave up in deploying my first application and thought that I should just switch everything I worked on back to ASP.NET. I went through this though process even when there was a team of highly skilled developers across the way that were working with MVC.

So, instead of struggling and giving up I decided to learn something new and ask for help. I learned more in that 30 minutes of setting up my new application on a server than I did in the previous 3 hours of Googling and struggling.

Wrap-up

There is a certain type of culture that goes with software development and engineering. One that almost demands that you understand and know something by yourself. It doesn’t have to be this way.

In my short experience I have found that developers that are at the top of their game have absolutely no problem helping out and teaching a newbie new things. So, instead of being a know-it-all, take it down a notch and know when you don’t know something.

 

Filed Under: Development