Earlier today I managed to upload a simple holding site for the project. Getting set up with any type of project always takes a bit of time. So, with best intentions, below follows how I usually go about creating stuff.

I didn’t want to do anything grand or really anything that would blow people away. I dig simple and fast, so that is what I did. There are certainly rough edges, but like anything… I will iron those out.

Pen and Paper

Every project starts with pen and paper for me. I have stacks and stacks of squared paper notebooks full of drawings and notes. I’m not sure if I could work without my notebooks... probably not.

First thing I did was sketch out a very simple layout of the holding site. As I said, I’m no designer.

You’ll notice that I write in CAPS all the time. I have to thank my Geography teacher many many years ago for always writing in CAPS on the whiteboard. Just easy to read… for me.

Everything I work on, starts like this. A simple sketch so I can get my idea down on paper and out of my head. No details, just pure layout, so I have reference to it as I build it. As I said in my previous post, I will design the site in the browser and not use a tool like Sketch. The reason for that is that it would take me a very long time. I’d rather see small gains over a few days then re-align stuff in my Sketch file. On top, the 60 day time limit I’m giving myself won’t allow me the luxury to do this (I’m just not good enough in Sketch).

Project set up

Every project, at the code level, has to start somewhere. As I’m going I’m making photos and screenshots which I can share in these posts. Simple Schedule already has a design folder where I put all these, including the logo I created in Sketch yesterday (in the early morning!).

Everything from design and code lives in iCloud Drive. Yes, weird! But it works for me.

Update: I had some feedback on iCloud Drive and generally storing files like these on the "cloud". I understand the risk. I also understand that it is probably frowned upon, especially in a corporate environment. The decision to move was a long one, with a gradual move to iCloud Drive... making sure everything works. I can only stress to try and see if this works for you. One project at a time and give it a chance to sync. At the start it was not perfect, but as time went on it got much better! I generally just work for myself, so it works for me. iCloud Drive has saved me countless of times this year, with full restores to my then dying laptop. It did it every time, pulling down everything without stress. Yes, there were problems with a few repos loosing their place with commits... nothing a git pull couldn't resolve though! iCloud Drive for me serves as a back up. My code is always checked in and pushed at first instance. Thanks Alec and Elliot for your comments.

I have two folders, one for “Design” and one for “Dev” - Dev being the one that has all my code projects. The design folder also lives in the code folder as an alias so I can jump between the two easily. Every part of the project will also have its separate folder which also have their own git repo tied to it. More on that in a moment.

So a typical folder structure that I would use for this project is:

‘simple_schedule’ - The main folder that holds all the parts pf the project from code to design.

• ‘SimpleSchedule.Design’ - this is the alias.
• ‘SimpleSchedule.Holding’ - this is the holding site.

There will be more down the line, for example I’ll add ‘SimpleSchedule.FrontEnd’ tomorrow and then in a few weeks I’ll add ‘SimpleSchedule.App’ or something for the Rails apps.

For the holding site I decided to use Jekyll. It’s super easy to set up, it doesn’t require a database and it’s something I used for many years. I don’t really like the idea of having a database laying around just for the holding site. This may change once I build out the marketing page down the road, but I don’t want to think about it just yet.

With the folder set up and the ‘jekyll new’ command run, I open up Sublime Text with the project. There are many text editors out there, like Atom and Visual Studio Code, but I just love the simplicity you find in Sublime Text. I was a heavy user of Atom but earlier this year I decided to go back to Sublime. It might not be as feature rich from just looking at it, but I find it really nails the balance. Plus it doesn’t run Electron.

I organise and tweak a few things with the default Jekyll install to a more organised folder structure. This works for me nicely as I have a particular way with these things. I am German, what do you expect?

As you can see, ‘_src’ is where the Jekyll specific parts are, this then builds into ‘dist’. I keep ‘dist’ out of the Git repo and I build the site on the server. More on that in a moment.

‘_assets’ is where I keep all my images, stylesheets, javascript and other things. I work for myself and always use CodeKit to help me compile and optimise everything I need. Yes, I did try gulp and others but it really is a bit too much… especially when you work for yourself. Again, this works for me. Plus I don’t have loads of ‘node_modules’ lying around in my code folders… I do occasionally use build tools for client work, but that is rare. I usually let them handle it after I hand off the project. CodeKit compiles everything into an ‘assets’ folder in ‘_src’.

First commit and deploy

Now it was time to set up my server to pull down my Git repo from GitHub and build the site for me. I personally use Laravel Forge to manage my servers. It’s powerful and I’m super happy I came across it earlier this year! It’s mainly based at PHP but with set up you can work with Ruby and others quite easily.

With the GitHub repo set up I opened up Tower. Tower is a Mac App that does git amazingly good. It’s paid but I urge anyone to give it a try. It’s great at organising your projects too! You can even have folders/groups. It’s really powerful and I wouldn’t know what to do without it. They also have a Windows app.

I already put a few ‘default’ styling files and some various other files, that I use across my projects, into the project. With that, my first commit to see if it all works.

I told my server which repo to pull and also told it to watch for changes to the repo, so it would grab it as soon as there is a change and then build the jekyll site on the fly. On top, Laravel Forge also offers Slack notifications when a build succeeds or not.

It was done, the site deployed and built without a problem!

Knowing that it now worked, I started to build the site.

Building the site

With the first milestone reached I continued work with budding it out. As I develop locally and running Jekyll, I keep Jekyll in a build mode which watches for changes. I tell CodeKit to look at the ‘dist’ folder and serve that site on the small web server it runs. Every time I hit save in Sublime, Codekit will refresh the browser. An added bonus to this is that I can look at my site on all my devices on the home network. Great for responsive testing! … although, for this stage it wasn’t too important to me.

I only needed the homepage at this stage. I built it out over the course of an hour or so.

The image above shows the completed site, in code. You can see how I go about using Jekyll here. I really love the Liquid templating language. If you want so see it in detail, just drag that image to your desktop... I'll think of adding some sort of pop at some stage.

At this stage it is probably overkill of what I have done and could have had one page with everything. But that is not how I work. I also wanted to try and pull in a .markdown file as an include, but figured it doesn’t convert markdown when you do that. No problem, there is ‘markdownify’ option that will help with that. If that’s a bit technical… sorry.

I always choose to have CSS and Javascript to the right of the HTML or code files. It’s a little bit easier to keep track of things that way.

The code above is not perfect but, once again, it works for me. Especially the SCSS, it might look weird but I find I can keep track of everything much better that way. I have a few predefined styles that I can reuse and you can see me using the ‘@extend’ keyword a lot.

In this case I didn’t need specific media queries, to size it depending on the screen size, because I try and build with that in mind from the start.

Getting it live

There wasn’t much for me to do except push my changes to GitHub. As this was only a holding site, I only pushed once, once the site was finished locally. On larger projects I usually have a ‘dev’ or ‘staging’ url and push them there first before pulling the trigger. We’ll do that once we build out the Front-end UI this week.

With it pushed up, I received the Slack notification saying it was deployed. And here it is.

It’s simple and will do the job until I figure out a better marketing message for the app. It loads fast, uses no hosted fonts and there is no tracking either.

The email box goes directly to MailChimp for signup. As I said previously, I’ll be running Simple Schedule through my company so you’ll be seeing my company details on sign up. Not sure if that might confuse some people.

Also, I wanted to have a small disclaimer about the sign up. I don’t like spam, I don’t like marketing email so I thought it was important to make it clear what I’ll use the email for.

Closing thoughts

Yes, it’s rough on the edges. Yes, there is no favicon or OG icon. The text on the page might not be perfect either. However, over the course of building the app I’ll slowly be replacing a few things as I go.

With this small achievement, I am now geared up for staring the front end UI for the app. I’ll be sharing details about this tomorrow and will be opening up the URL for people to follow along.

I wrote this article mainly for myself to follow along when I look back at it at some stage. If you like to contribute, please email me or let me know via Micro.blog.

For other posts on the challenge, check out the links below:

1. Code challenge - from zero to web app in 60 days
2. Code challenge - Prelude and Day 1 - Setting things up
3. Code challenge - Day 2