Starting In The Front-End vs. Back-End Web Development

Having been around a lot of website & app development for the past 15 years, I see two major ways to pursue a web or app solution.

You can either approach it from the front or the back.  This just means that either the project starts with design (the front) or it starts with code and database development (the back).

Let’s just say the front-end design approach is more suited to success these days in creating a web or mobile app.  It has more of an agile (not the method, but really agile) way about it. If you are going to develop a software app, showing customers what you are going to first develop, then develop it, makes total sense.  This is all my opinion though.  When I hear that a company is going to develop all the back-end tech first and then figure out how the app will be approached from a customer perspective, I get a little nervous.  The front-end generally dictates the back-end.  But, once again, there are a lot of perspectives on this.  If we were developing 50 years ago, and were using a mainframe, we would have to build the back-end first, because there was virtually no front-end.

However, in todays environment, the largest of applications require some sort of front-end design sooner than later (preferably upfront).  I will give some great examples of success at the end of this article.

In modern web dev apps I generally see a front-side approach.  That does not mean that the back-side is not a way to develop.  It would really depend on the type of project.  It can turn to a situation where the front and back meet in the middle. That Middle approach may be a happy medium.  The Middle approach to me is just the second stage of the Front-End.

Back-End Approach

If the project is completely not dependent on customer user interface design or known business model constraints then back-end makes sense.  A good example would be developing an API.  An API (Application Programming Interface) is a way computers connection and pass information around.  So without any serious user interface, an API generally has no front-end.  But even with an API, I prefer a front-end approach, because sometimes it take a front-end to understand how the API needs to work. Another example would be a database solution that has no user interface.  Let’s face it, if there is a User Interface somewhere involved, even an administration screen, the front-end approach makes total sense.

Front-End Approach

The Front-End approach is relatively straight forward.  One tech team I work with typically will design as many screens as possible in advance, so they have identified all the necessary back-end programming needed.  Once the company or client has agreed to all these designs, they move on to an HTML/CSS version.  At the same time, they typically will start to do some of the heavy lifting back-end parts of the project.  This depends on the sophistication and complexity of the application.  So the Front-End approach ends up meeting the app code in the middle.  It’s a necessity.

The Iterative Approach

During project development, software development companies find stuff that needs to be added or fixed.  I always refer to this as the plumber who needs to open up the wall to find out what needs to be done.  No project is exactly the same as the design.  There are always slight changes, typically made by the product owner/manager. These are the fixes you could not think of initially or bugs that come into the process by mistake or because of an unexpected sequence of events (stuff you could not foretell).

After the first version of a live software project, also called a Beta or an MVP (Minimum Viable Product), there is the next version.  Typically these next versions and changes don’t always start from the Front-End, unless there is a redesign.  The next set of changes go through the same set of processes again and again.

The Final Point

Well, let’s just say that Back-End driven development is good for certain types of projects.  Let’s just say that it can lead to a major problem if the project is consumer/customer facing or consumer oriented, especially if the Back-End driven project was not developed with real customers in mind.  If the customers enter the process later, it may still be ok, especially if there is a budget to redevelop the entire project (front-end design) from scratch.  Most start-ups and divisions of companies don’t have the luxury of being like a government project.  There are many reasons why software projects fail or have to be redeveloped from the beginning.  In order to make sure this does not happen, starting with the Front-End method of development can help seriously reduce this problem.

Remember to buy my book.  Just click this link and it will take you to Amazon.com, where you can purchase Thinking Like A Start-Up.

Publishing Your Own Book For Free (For Real This Time)

This morning I published my book Thinking Like A Start-Up!  It is available in paperback form for $19.95 before a discount and for the Kindle for $9.95.  The book is about 214 pages and has a lot of thoughts about start-ups.  It is meant for start-ups but also corporate IT and product management professionals.   You can click this link to go buy my book on Amazon.com.  I promote you to do it.  I also promote you to write up a bang up review and give me 5 stars on Amazon.com.  Now if you are my relative or a good friend, this is a given.  If you are just by chance reading my blog because you randomly found it, then please read my book and give it whatever review you want.  I am just happy you have heard about my book.

I think it is a pretty good book.  You can beg to differ.  Does matter much to me.  Most important to me is getting a few sales and getting the book out there!

On October 21, 2014 I wrote a blog article about how to publish your own book for free.  In that article I mentioned a website called Createspace.com, which is a subsidiary of Amazon.com, where you can publish your book. I have heard of a dozen of these sites out there, but if you are going to do it, Amazon.com sounds pretty good to me.   This article will show how I went ahead with publishing my book, despite a bunch of negatives.  And at this point, my Amazon.com book is now available, as of this morning, and I actually saw 5 sales in the royalty report.  I am actually making $67.25!  I am ecstatic.

When They Say Something Is Free, You Know There Is Always A Catch!

What I did notice along the way is you can pay for expertise and services.  I just decided to skip these add-ons.  Createspace.com has a service where they will make a cover for you for, for example.  They have paid services where they will edit your book, carry out design services, publicize and market your book and various other services.  I would believe these services are excellent.  But I was determined to publish my book for free!

The Negatives

I would say the biggest negative is my book is pretty plain and simple.  If you look at comparable books, they have nicer covers.  The other books have cooler graphics.  They probably have much better, nicely edited writing.  I did my own editing and proofing.  So it may be ugly in parts. But the biggest issue I ran into is I did not pay for Kindle conversion services.  So, when I looked over what happened in moving over the documents to the Kindle version is the book is pretty unreadable.  This was mainly because I did not put in the time to do the Kindle conversion properly myself.  I just took the print version in a word .doc form and jammed it into the Amazon Kindle site.   I also realized late in the process that I probably should have printed the book under my corporate name, not my name personally.  So, you will notice when you buy my book, I, Dan Gudema, is the publisher.  This may seem a little unprofessional.

You Pay For Professionalism

Another issue I ran into is I decided late in the game to add these quotes and quips to each chapter. When I showed this to my cartoonist friend, he wanted to create graphics for the book.  A week later, I called him and he confirmed that it would take him at least a month or 2 to create these graphics.  Even he said, well why don’t you just publish you book today and we will add the graphics later on. Sorry about that.  My first version of Thinking Like A Start-Up will not be that nice…. but there is always going to be a nicer edition 2 out.  Finally, another weird issue I found out about at the last minute is Createspace.com will not publish your ebook or Kindle version.  I had to go to http://Kdp.amazon.com and it almost felt I like was starting over with the process, which did not make a lot of sense to me.  I may be adding another article covering exactly step by step what to do with the Kindle version, because it was a bit rough, and what came out of it was rough.  So, if you can afford it, pay a publisher to do it right.  If you are cheap like me, then do it yourself!

What I Learned From This Experience?

Well, first off it has come to the point where anybody can create a book and do it for free.  My point in this blog article is I just feel sometimes you just have to stop talking and do something.  I needed closure.  I realize there may be a spelling issue here or there.  I also realized there may be some run-on sentences, sentence structure problems or wording issues. There are definitely some minor glitches in the book.  but you know, that’s life when you are self-publishing.  The point is, sometimes you just need to go for it, whatever it is and find out what happens.

Publishing Disintermediation

As far as the overall view here. What I am seeing is the removal of the middle man.  If we can all publish books on what we want to pontificate on, and we are able to get people to actually buy our stuff, we are seriously removing the agent and publisher from the process.  Now, in my case Amazon.com is taking a hefty fee, like 55% of the sale, but who cares, I was able to publish my book!

Dr. Frankenstein The Writer

So, I experimented and made $67.25.  Not sure if I will make a dime more.  At least I am hoping to double that, as long as family and relatives feel obligated to buy my book. I also put 100 names of family, friends and colleagues that I acknowledge in the book (to get them to buy the book)!  This is a silly practice, but maybe it will get me an additional 3 sales.  I would like my publishing experiment to be a money making venture.  However, for now that will have to wait.  I am about 75% complete with my next mini book, which is going to be the first in a series on the tools that tech start-ups to get started, get presentable to investors and generally figure things out.

 

 

How To Migrate A Massive WordPress Site

A client of mine called me and told me their WordPress website was growing too big for the server it was on, even though it was a VPS, that the WordPress site was going offline periodically.  They asked me if I could help them migrate this gigantic site.

When I refer to gigantic and WordPress in the same sentence, to me that simply means that instead of megabytes of data in the database they are dealing with gigabytes of data in the database.  And instead of thousands of files, there are let’s say hundreds of thousands of files.

Small Biz Now Has Enterprise Level Issues

Luckily I have dealt with both the small and large servers over the years.  The real question has always been, can WordPress handle this high volume of DB and File issues.  Well, it can, but the issues have to be thought out and a problem like this turns from dealing with minor WordPress hick-ups to corporate-level Unix issues.

Why They Had To Migrate

Their server was just not able to handle what they were doing in terms of server speed, hard drive space, etc.  And this was causing the website to be unmanageable.  So, it was time to migrate. However, this was not your run of the mill WordPress migration.  It had all kinds of potential problems associated with it, like thousands of uploaded files, hundreds of thousands of records in some tables.

Why My Normal Tools Won’t Work

For instance, the database was too big to download using PHPMyAdmin.  Not that this is a big deal, it’s just if you have been a WordPress person for the last 5 to 10 years like me, you may not have all the tools in the tool chest to deal with this. I typically use a desktop ftp program to do this stuff, but not for this size. Using local ftp clients means downloading to your Mac or PC. It is not recommended at this level. For instance, if you are not on a fast enough download client, you are screwed…

The Tools

The reason I am writing this blog entry is so I can grab all those tools again in the following order in order to do this kind of migration again.

Here Are The Steps I took:

  1. Sized out the proper new server for the client. (My preference is StormOnDemand by Liquid Web, WHM/Cpanel cloud)
  2. Had the client buy the new server and handed over to me the login credentials.
  3. Received all the login credentials I need from the original server.
  4. Created a new website in WHM/Cpanel, generating a new IP.
  5. Created a temporary domain name for the new site and pointed the DNS to the IP.
  6. Created a Database Name, Database User in CPanel with the same name as the old DB Name and User.
  7. From the Shell command line (I use putty.exe) I used the tar command to zip up all the files beneath public_html.
  8. From the Shell command line I ran a mysqldump of the old database, creating a command line .sql file.
  9. From the Shell command line I ran FTP as new account name (not root) on new server and Put the tar file (like files.tar.gz) onto the new server.  (it was in the multigigs)
  10. From the Shell command line I ran FTP and Put the .sql file onto the new server. (it was over a gig)
  11. On the new server from the shell I unzipped the tar file.  Remember to position this right above where you want it to land.
  12. On the new server I switched over to root user (su root) to be able to import mysql.
  13. On the new server from the shell I ran a mysql import command which updated the database.
  14. Finally, while in test mode, there were two lines wp_options which need to point to the right domain.
  15. Make sure all the previous plugins are activated.
  16. We tested the new site with the temp domain name.
  17. Once we were ready, we switch the old IP at the DNS record to the new IP.
  18. Final thing is to rename the site name from the temp domain name to the actual domain name.
  19. Everything went relative smoothly and the site migrated.

That is all the actions I took, now here are the commands I used specifically:

he tar command to zip up the files to a .gz from right above the public_html directory:

The tar command to unzip the files from a .gz right above the new public_html directory:

The FTP commands I used to connect from Linux server to Linux Server:

The mysql command I used to dump the entire mysql database at the command line on the old server:

The mysql command I used import the entire mysql database at the command line on the new server:

Conclusion

Hopefully if you are reading this, you will use this to reduce the amount of time I took looking around the web for the right commands to do this. You may have to look up those other websites, because each of these commands have dozens of options. For instance, if you need to move more than one file at a time, using FTP, you would have to use mput and not put. So, keep up the good work. I hopefully will use this guide for myself next time.