DEV Community: Legobox

Introduction to ML: How to frame data.

Osita Chibuike — Sun, 26 Jan 2020 14:29:01 +0000

This piece was originally posted on my blog at legobox, if you want to follow the full series on Machine learning and my experiments with software development, check it out.

Introduction to ML: How to frame data

Origins.

Data has always been a problem, understanding it, dealing with it, sourcing it. Yea it's always been a dread to work with data, therefore the process of presenting data in understandable form also known as framing is pretty important.

Data as we know it can take all shapes and forms, from the text, images and audio files to CSV, SQL, and other data structures. Therefore in machine learning, collecting data, arranging data, and understanding it, is of utmost importance.

Framing is the process of arranging data in ways that can be easily understood by machine learning models.

In the piece we are going to explore more on framing and how it works, how we could use it and libraries in python which allow us to work with framing data easily.

What's framing.

Framing is about arranging data in ways that can be easily understood by machine learning algorithms, pretty simple. With supervised machine learning, Framing is seriously important.

Supervised machine learning can be viewed as ML systems learning how to combine input to produce useful predictions on never-before-seen data. which almost defines all of machine learning.

With framing, here are the key concepts to learn.

The key concept's of Framing: Features and Labels

Labels: These are outputs we are trying to predict, i.e the y in the y = mx + c equation.

Features : These are the inputs, x , these can be anything ranging from words / text to numbers etc.

Simply put Labels are the outputs, and features are the inputs, make no mistake though, Inputs and outputs, in this case, are not

Example

For an instance of data we can break the data sets into two categories for the process of training out models, These are particular instances of data relating feature to labels, these categories would include:

Labeled examples
Unlabelled examples.

The labeled examples are the ones in which we have features associated with their corresponding labels, while the unlabelled are those with no corresponding label.

For example, here's a labeled example of California housing data.

The unlabelled examples contain features but no label, This is meant for testing after training in order to ascertain and predict the values.

In order to expand our understanding of Framing, we have to take a brief look at models how they work and how it affects how we frame data.

What are Models.

We all know what models are, the usual slim beautiful women, on runways and IG, but in the study of Machine learning and mathematics in general, Models are definitions of relationships between features and labels, i.e they are the relationship between a set of inputs and a set of outputs, therefore, they outline how a certain input produces a certain output.

Models are definitions of relationships between features and labels

There are two major phases of a model's life.

Training - The model looks at several examples, draws relationships between the features and the labels. To learn how they work.
Inference. - The model begins testing out predictions on new data to previously unseen before.

So how do we get started with defining features and labels from our data? To do this in python (which is a very common base for practicing Machine learning because of the abundance of tools and libraries), we would use Pandas in reading and describing out data in tabular form. So let's have a brief look at this.

Getting data: A super brief intro to pandas.

Pandas is an open-source, BSD-licensed library providing high-performance, easy-to-use data structures and data analysis tools for the Python programming language.

Here's a sample call to obtain data using pandas.


    californiaHousingDf = pd.read_csv("https://download.mlcc.google.com/mledu-datasets/california_housing_train.csv", sep=",")
    californiaHousingDf.describe()

In this case, we collected data of the California real estate from the hyperlink using the pandas read_csv method, which would read the CSV data into a data-frame.

In pandas there are two primary data structures, these are.

DataFrame, Which is like a relational data table, with rows and columns.
Series, which is a single column.

Dataframes contain one or more series and a name for each series.

One way to create a Series is to construct a Series object. For example:

DataFrame objects can be created by passing a dict mapping string column names to their respective Series. If the Series don't match in length, missing values are filled with special NA/NaN values. Example:

But most of the time, you load an entire file into a DataFrame. The following example loads a file with California housing data. Run the following cell to load the data and create feature definitions:

Essentially data frames are two-dimensional descriptions of data. pretty lit stuff.

To define our feature, To start, we're going to use just one numeric input feature, total_rooms. The following code pulls the total_rooms data from our californiaHousingDf and defines the feature column using numeric_column, which specifies its data is numeric:


    # Define the input feature: total_rooms.
    my_feature = californiaHousingDf[["total_rooms"]]

    # Configure a numeric feature column for total_rooms.
    # here tf is tensorflow.
    feature_columns = [tf.feature_column.numeric_column("total_rooms")]

In this case, my_feature defines our features. To define our labels we could use, the median_house_value, to define this as a label we simply reference them from the data frame


    # Define the label.
    targets = californiaHousingDf["median_house_value"]

Thus we now have our features and labels in two different variables, for our models to train on.

Conclusion.

In this piece we've learned about how we go about framing data and separating the input and output into variables we can use in our models, We also took a brief look at models and how we can work with them. In our next article we are going to look at the Linear regression model, probably the simplest model in machine learning and how it works, to get a better insight into how other models would work to achieve the same goal.

Journey to fullstack developer - Authentication with Redux - promise based.

Osita Chibuike — Wed, 22 Aug 2018 04:53:06 +0000

This article was originally posted on my blog at legobox

The weeks so far.

In the bid, to be frank, I'm going to write with respect to my own laziness, yes I have been really lazy about this project. I have a problem of not usually completing passion projects but I'm trying to change that which is why I have to actually write about my laziness too. In the bid to get my full experience across. Sometimes I actually think I don't like coding so much if there's an easier way to solve a problem I'd probably take it.

So far spectre has been undergoing slow progress, thanks to me (being sarcastic here), But I'm sure to improve that. This week completed all authentication related proceedings and I had the opportunity to really have a good look at authentication in react based projects and come up with some overview of the process, which I think I'd love to share.

Building out Authentication - Redux based

There have really been a lot of articles written about Authentication as with that came many idiosyncrasies with relation to the process, a lot of the time there were not enough explanations as to handle some scenarios and in other instances, these ideas were not production ready.

On one hand, we had the articles which do well to describe how it would be implemented but fail to account for how best to set up the system so that it's able to track the authentication status with relation to the token state provided by the server. i.e what if the state of the application says this user is logged in, but the token is expired, and also what if the case is reversed. and heck there were other things to think about.

Do redirections take place in the components or in the actions?
How do we handle asynchronous operations from actions?
What the best practices when working with redux.

At the end of the process, I came to the following conclusions,

Promises are the way to go in handle redux based asynchronous actions, they are possibly best for all redux based actions.
Actions are meant to focus on just performing actions of communicating with the servers and changing state, nothing else.
Route changes have to happen in the components only, and nowhere else.
All APIs actions have to be managed by an API class powered by axios. since its promise based, it fits directly into the promise based architecture of the system.
Since we are taking all things asynchronously, use the async-await pattern where possible for more intuitive syntax.

Relation between tokens and states.

In the process of monitoring state, there 2 major properties that decided if a user was logged in or not.

The token received from the server meant to serve as the access token.
The state of the isAuthenticated state property true or false. This property is dependent on the token property.

With these two there were a few combinations to monitor when doing an auth check.

isAuthenticated = true, the token is found (User is actually logged in)
isAuthenticated = false, the token is found (User is logged in, but for some reason, the state is messed up)
isAuthenticated = true, the token is expired (User is not logged in on the server anymore, so we have to correspond)
isAuthenticated = false, the token is expired (User is really logged out ).

I wrote an article in the past about a structure of this sort, it explains the details but in this process I changed a few things from that article, I think I would have to update it, but here are a few things to note, if you haven't read that article, there's a link to it. It would help you understand what's going on here.

From that article there were 3 major components handling routing.

AppCheck container - Taking charge of updates on the routes to note if the user is logging in or logging out, in order to do the appropriate redirect.
EnsureLoggedInContainer - making sure the user visiting these routes is authenticated
EnsureVisitorContainer - making sure the user visiting these routes is a visitor(not logged in).

Well without further ado here are my proposed changes to these components.

On AppCheck component, I added a componentDidMount lifecycle hook to check for the presence of the token in relation to the state and make the appropriate changes to the state.

componentDidMount(){
    const { currentURL, pages, dispatch, isLoggedIn } = this.props;

    // note isLoggedIn is mapped directly to isAuthenticated by redux connect

    let token = this.props.cookies.get('uat');
    console.log(token);
    switch (isLoggedIn){
      case true: 
        if(!token){
          dispatch(actions.logout()); // this action automatically changes the state of isAuthenticated to false
        }
        break
      case false:
        if(token){
          dispatch(actions.autoLogin()); // this action automatically changes the state of isAuthenticated to true
        }
        break;
      default:
        break;
    }
  }

Apparently, this is the only change I needed to make to my checks on AppCheck the other checks (EnsureLoggedInContainer and EnsureVisitorContainer) pretty much remain the same.

Redux setup with promises.

In the project, all actions returned promises, well all actions that were going to be called by the component via the mapDispatchToProps function. Using the thunk middleware from the redux-thunk setup promise functionalities were provided and I was able to write action functions like this.

import actionType from '../action-type';
import {api} from './'

export const autoLogin = () => (dispatch, getState) => new Promise((resolve,reject)=>{
    dispatch({
        type: actionType.LOGGED_IN,
        payload: true
    })
    resolve('success');
}).catch(err=>{
    console.log("error here", err)
    throw err
});

export const signup = (params) => (dispatch, getState) => new Promise(async (resolve, reject)=> {
    // do cool stuff then resolve/reject
    try{
        let res = await api.post('/auth/register', params)
        dispatch(autoLogin()).then(()=>{
            resolve({status:'success',message:'You successfully signed up!!!', ...res});
        }).catch(err=>{
            reject({status:'error',message:'Something went wrong!!!', ...res});
        })
    }catch(err){
        console.log(err)
        reject(err);
    }
}).catch(err=>{
    console.log(err)
    throw err
});

As you can see signup function and autoLogin both use promises to handle their operations. Thus allowing us to defer operations based on these actions until they were completed. In order to interact with API endpoints, I wrote up a class called API for interacting with the APIs via axios.

import axios from 'axios'

let headers = {}, running = 0;

class API{

    SIGNUP = ''
    LOGIN =  ''
    CREATE_PROJECT = ''

    constructor(options = {}){
        this.axios = axios.create(options);
        this.headers = {}
    }

    send(type, args) {
        running++;
        const respond = (func, resp) => {
            running--;
            if (!resp) resp = {};
            func(resp.data, resp.headers, resp.status);
        };
        return new Promise(
            function(resolve, reject) {
                this[type]
                    .apply(this, args)
                    .then(resp => {
                        respond(resolve, resp);
                    })
                    .catch(error => {
                        let resp = error.response;
                        respond(reject, resp);
                    });
            }.bind(this.axios)
        );
    }

    get(){
        return this.send('get', arguments)
    }

    post(){
        return this.send('post', arguments)
    }

    put(){
        return this.send('put', arguments)
    }

    patch(){
        return this.send('patch', arguments)
    }

    delete(){
        return this.send('delete', arguments)
    }

    getHeaders(){
        return headers
    }

    getHeader(name) {
        return headers[name];
    }

    headerIs(name, value) {
        return headers[name] == value;
    }
    setHeaders(new_headers) {
        headers = new_headers;
        return this.renew();
    }

    setHeader (key, value) {
        this.axios.defaults.headers.common[key] = value
        return this
    }

    removeHeader(name, norenew) {
        delete headers[name];
        if (!norenew) this.renew();
        return this;
    }
    renew() {
        this.axios = axios.create({
            // baseURL: process.env.API_BASE_URL,
            headers: this.headers
        });
        return this;
    }
}

export default API;

At its base its a simple class actually for manipulating headers and making sure to provide the proper bearer token on all requests, since axios changes are effected across the app, changes on this class run through the entire project via one instance defined in the index file

const api = new API({
    baseURL : env.API_BASE_URL,
})

This is the instance imported in all actions.

Toasts and Notifiers.

It's good UI to let the users know something has happened or something is happening, or if an error occurred. With the promised based flow its usually really easy to catch these errors and since all actions "then" and catch phrases are handled in the components, we can essentially use a component-based toast handler or notifier.

In the project, I opted for the react-toastify plugin component its available on npm.

Conclusions

This week would complete all respective frontend implementation hopefully, I really do hope to make this count (putting on my clown nose). After this phase the APIs would be explored and I'd get into the nitty-gritty of how spectre works with relation to version control systems and servers.

Journey to full-stack engineering - Building lean frontends.

Osita Chibuike — Wed, 08 Aug 2018 17:01:04 +0000

This post was originally published on my blog at legobox.

So it's been a little over 3 weeks since I started building out spectre. 2 weeks ago, all designs were completed and it was time to get into the nitty-gritty of implementation. In this phase starting out with the front end was the most reasonable idea to me, it usually is the most reasonable idea.
Most would vouch for building out your APIs first, but that requires some real significant foresight, in this case, the app has a simple core.

Managing projects deployments to servers.
Managing processes run via ssh and keeping logs.
Managing users and collaborators.

These are the major points that required an API, therefore I’ve decided to take on frontend first so as to be able to get a proper view of how these APIs would be used.

Thought process

My development process is largely deep in the scrum methods, but I combine with the use of KPIs to get the most out of myself, Therefore over weeks I set out tasks to accomplish on scrum board and attach KPI scores to them and proceed to try my best to reach a target KPI score, sometimes I hit it, sometimes I don’t, but it always get’s the ball rolling.

Tools and stack

Being an advocate for the SPA (Single page application) I really love them in terms of structure. an SPA provides several benefits, for those of us who are not familiar with the term, let's start from the beginning.

SPA are applications whose entire frontend is loaded in a single file (index.html typically) this allows them to load all their resources once and have the frontend operate seamlessly without the need to load other pages from the servers.
The only data loaded after loading an SPA app is JSON response and data that might be required in different areas around the entire application.

Framework
In this case, my SPA tool is the react javascript framework. I only started coding on react about a year plus, for the most part, It's been a really cool tool to use, good structure in terms of features and allow for real quick prototyping.

I also combine react with a few other libraries which serve different purposes in the development process. a few of these include

Reactstrap - A react based alternative to traditional bootstrap (quick prototyping here 😒 )
Chart.js - A javascript library for displaying charts (as the name implies)
Redux - The almighty redux, state management in react doesn’t come better than that.

Servers
I’m using a VPS box to serve the project for live preview.
At the moment the following pages have been implemented.

Homepage
Login
Signup
Dashboard

These were created in direct accordance to the design specs, all implementations can be found on the server preview site

Deployment
The project is set up to use gitlab’s CI integrations to set up a CI system which deploys to the servers whenever I push to master. To learn about that, I wrote a piece once upon a time about that.

Setting up the servers was accomplished using ansible, using docker on the project is just overkill to me cause all other projects on my VPS running on the same stack most of the time, except for custom software or situations that warrant them.

The way forward.

During the course of the week, I’ll be implementing the other interfaces as designed, in order to get a clear idea of what it means to be a user using the application. would likely call for some A/B testing and some site analysis to get a clear glimpse of all pressure points using the tool. Being a saas app it's important the project focuses deeply on the workings and functionality since it, not a social facing system.

Conclusion

By the end of the new week, I should have all the interfaces implemented and ready to go, alongside the basic setup for the authentication features.
Building out a platform is always fun at some points and for the most part, it opens a partway to a whole lot more. In terms of work habits ethics and time management, maybe I’d write about that some other time, but at the moment we are making good progress.

Journey to Full-stack, Week of design 2.

Osita Chibuike — Tue, 17 Jul 2018 05:14:01 +0000

This article was originally published under my blog @legobox

Thoughts.

Since the process began, a large portion of the process focused on designs and having the ideas of UX - user experience with respect to the application in mind. For the most part, we've been able to do this. Until minor setbacks.

2 weeks ago I wasn't exactly able to make much progress with respect to design and development mostly due to the fact that my computer got damaged, Fixed up the next week, so project's back on track. For those diligently awaiting updates with reference to the series, really sorry for the lazy week.

Moving on, I've been able to complete designs of the application. Lets have a look at progress made in this process ( sounds like a rap ).

Progress.

Last week was also design focused, targeted to completing the design phase, all the while still keeping in mind the ideas of minimalist designs, and making sure not to bug with unnecessary information.

Designs I was able to complete included the following.

Account Management

As the name suggests, this interface focused on the interface of the profile management sections where users would be able to make changes and updates to their profiles.

Token management

Project spectre would use tokens from GitHub, Gitlab or Bitbucket respectively in order to manage the deployment of the project based on web-hooks from these services. This interface focuses on integrations and tokens with respect to these services. So as to be able to access web-hook requests.

Billing

This interface deals with the billing and subscriptions of the users with respect to their plans on projects and servers.

Improved designs.

The following designs were improved in multiple aspects and extended to include and improve their atheistic. These interfaces include the following.

Project management interface
Home dashboard interface

Shortcomings and achievements.

In the process, there have been several shortcomings, and some achievements, These include the following.

Shortcomings

I'm pretty slow in design, it usually takes me a bit more time but In the process of working through the week I've been able to improve.

Achievements

I've been able to clearly get a grasp of the entire project structure and ready to enter the implementation phase.
All designs have been completed ## Targets of the week.

The new week (this week) would be focused on implementations of these designs, the idea is to build out the initial structure and then focus on soft touches ( areas that can be improved ).

Interfaces would be implemented in react, Those I hope to fully complete this week include the following.

Landing page
Login Page
Sign up page
Home dashboard

Conclusion.

Building out has been tasking, but for the most part is that it has more to do with self-management and process. This means the process of managing the software development cycle as well as project planning, go a long way in deciding the viability and feasibility of a project.

As a one-man team, sometimes it feels overwhelming, that's why it often pays to have all steps ordered in detail and sections to session blocks to as to enable one develop in an organised manner.

Journey to fullstack engineering - Week of Design.

Osita Chibuike — Mon, 02 Jul 2018 01:30:48 +0000

This is article is part of the journey to full-stack engineering series, My journey in building whole products as a one-man team — Hopefully.

2 weeks ago (review)

2 weeks ago I began this process of trying to create full products taking to view all aspects of the product development process, My aim is to simply build useful applications and encourage other engineers to have the entire product in mind when trying to build applications, be they part of a team of a one-man army.

Like I explained in the last article, I’m just a curious soul who happened to enjoy the process of learning and building software, therefore, I never really stuck to any particular aspect of development with a strict label, therefore I love to take on any aspect I have to. thus, code wrangler here. From the last weeks' article I decided to create a product, so here’s a brief overview of what the product is. I got a cool code name for it though, I like to call it Spectre — Like the James Bond movies.

A deployment management system for developers and teams to manage the deployment of code from the repository to the server.

Essentially spectre is quite equivalent to Laravel’s envoyer, but in our case, we would handle deployments for many different stacks and project types. e.g create-react-app projects, vue-cli projects, laravel projects (obviously), express projects, over time (with this entire thing being successful) I aim to integrate more stack types to the project.

Last week ( Design all the way )

So this week was focused on design and app structure, this is pretty much the very first step in developing applications for me. It gives me insight into how users would use the product and how it would flow with respect to performing its designated actions, for more user-focused applications like social networks and eCommerce, this process would pretty much be proceeded by process and sessions focused on customer analysis and user profiling, but in this case I didn’t follow through on those cause I pretty much know who my target users are — platforms and developers looking to push code and manage seamless deployment, without much technical overhead.

So with all set lets have a look at the proposed application structure.

I usually manage projects using trello to create broad overviews of weekly features and then using todoist in placing these into daily activities and development sessions be it code or design.

Homepage designs.

Homepage and landing pages are usually the places to really do conversion, and I wanted to create something beautiful, but at the same time simply and get the message across fast and quick, I intended to create a gif though which would display a sample of the app in use as part of the page setup but I didn't have that yet, so at the moment I settled for illustrations.
My skills with illustrations are pretty rusty though but I think I pulled some decent work on those. getting better with practice. here’s a preview, most of the designs for the project are available on dribbble

I think its still a bit rusty, speedy work here, but the home/landing page is going to be undertaking lots of changes as the project goes along, therefore I’m not trying to have everything in there on the first go.

Up next is the login and signup sections.

Login and signup

With login and signup, I wanted to have a different set of illustrations and go with the central card design, I think not many developers oriented products focus on design concepts like this so I wanted to do my best or whatever I’ve got rather in pulling this off.

For the most part, I think its okay, but there could be several adjustments and Improvements to be made to these sections, I’d love to get some engagement from designers in the house and see what they can make of these, hopefully getting some ideas of ways to improve on the concept.

For the most part, I’m going for a minimalist concept, the next section is the Home Dashboard where users can get an overview of their projects which are being managed by the platform.

Dashboard

This page would give the user a quick overview of their project or projects and help them get a broad overview of things, form the design, I intend that the dashboard handle on project overview at a time, as projects would handle servers and have collaborators, manage deployment hooks and offer consistency checks using heartbeats.

Although I think this page too could need some improvements and upgrades, for the most part, this is a basic overview of what it would entail, I’m working on improving as I go along.
next is the project settings.

Project settings

The above is the settings page for the projects, This section would allow users be able to manage their project details and change certain information and variables with respect to the project, same as the rest of the design process, it’s aimed to be minimalist and straight to the point.

This is the Project’s Server management system, this manages the servers the project is connected, it would allow users to be able to add, remove and update servers with new keys when needed.

This section would manage the collaborators of the project would the owner account have supreme control over the project, with the permissions to both delete a project, assign admins and limit other users access to the project.

Work in progress

At the moment the design process is still in progress and I aim to integrate whole functionalities into the project in order to have really usable products.
Other designs upcoming with relation to the project include the following sections.

Profile / Account management
- Profile Management
- Billing and Credit management
Project Settings
- Creating new server modal
- Adding new collaborator modal
Errors and Toasts
Improvements on
- Home page designs
- Dashboard designs

Conclusions

At the moment I’m still working the design phase, as a designer, it’s more about getting a feel of what the user experience using the application and making as intuitive enough as possible for them so they have a less steep learning curve in using the app.

A lot of these would come down to getting into the mindset, at the moment I’m predominantly thinking as a designer and usually, it’s usually a revealing process. For the most part, though I work on designs during the morning sessions, I have better energy during those sessions, focusing on code-based sessions during the late afternoon sessions. My primary design tool is Figma, not an advocate or something like that, I just really fancy the tool and actually rated it as a 10 in designing cool UI/UX experiences.

By the end this week, all designs with relation to the profile management would be completed and It would be a deep dive into the development processes involved in building out the solution.

Journey to fullstack engineering.

Osita Chibuike — Sat, 23 Jun 2018 15:51:46 +0000

This article was originally posted in the legobox blog

Hmm fullstack 💭

In the year 2011, I started coding semi-professionally, It's a bit difficult to explain what that means though, but In essence, I was creating little projects which some individuals find interesting. I had no specific learning path in development and my strategy to learning, was almost like the Nigerian super eagles' strategy, solve your problem as they come ( as e dey hot).

This forced me to dabble in a lot of things ranging from frontend development using HTML, CSS, and Javascript, at its infancy as of then to working with PHP and MySQL for the database, or python in place of PHP when a friend recommended it.

This is not a piece on my story, but I just want to say I never knew when I became a full-stack developer, didn't learn with a coding boot camp, never been to Andela and what's more only met the coding community in 2015, since then I learned about several other tools and technologies that enabled me to do better work. I learnt to code for the love of it, I was hooked, I still am. but then the question came to mind,

Am I really full-stack?

See full-stack is a bit complicated for some to believe that someone could actually embody all attributes of full-stack development, but in order to me to really bring it to view, we have to look at what it would encompass as a whole.

UX / UI experience as a designer.
Frontend Development and Interface implementation.
API development and Backend Development
Deployment, Testing, and Development Cycle management (DevOps)

In each item in this list there are several more checklists to be met, so how would one respond to a title in which each section requires several if not some really extensive understanding or knowledge in each area?

Is the full-stack myth real?

Full-stack developers are real, yes I said it they are real, for the fact you haven't met a real one doesn't mean they don't exist, and if you've met one, then you surely know they are real, even more, I think full-stack developers go-ahead to build businesses and products because they gain an integral ability to see the entire pipeline as a whole and not just separate components. For that reason, I think there are 2 major types of full-stack engineers.

please the following terms were coined by me and me alone, no other should be held responsible (aka, they are not real things outside of this article)

Single point full-stack developers -- These developers usually know one part better than the rest, and therefore they would usually be able to communicate with teams working in the other sections. Outside of the team, they'd only take on the other sections if absolutely necessary and would usually be reluctant to even look for advancements in these sections.
Product focused full-stack developers --These engineers are more product inclined and therefore find it blurry seeing a separation of concerns between the different sections, they are usually looking at the product as a whole and would usually work in order to make the best features available to the central product, these guys typically make good freelancers and may not perform well in a large team.

Yea there's a third (The Liars) - These guys are novices in every section, even the once they seem most prominent at, in the end, they are hobbyist in all areas.

So in order to become a full-stack we have to understand where we fall under, Modern day software development has opened up resource to a whole lot of tools that confuse more than they help, and full-stack development has become a real beast.

Modern-day full stack.

A newbie looking to become a developer today is in for a real fight. but it gets easier as you go along. The repo link below gives you an insight into what it means to be a modern day fullstack developer.

https://github.com/kamranahmedse/developer-roadmap

So here’s an overview.

In the end it all comes down to 3 major plays,

Frontend
Backend
DevOps

Frontend Developement comes down to the frameworks, but these are easier to understand once you get the basics down.

HTML
Css
- On the advanced side
- Preprocessors
  - Scss
  - Less
  - PostCss
- Css Frameworks
  - Bootstrap
  - MaterializeCss
Javascript.
- The battle of the frameworks
- React
- Vue
- Angular
Testing
- The less known tools of frontend development
- Jest
- Mocha
- Karma

This goes deep. But I’m pretty sure you get the gist. Backend Development on the other hand is another deep trench.

Backend development is really deep and would require another article to really look at what’s going on there in 2018, but a simple overview would show the following.

Backend development revolves around to sets of languages

The Scripting Languages
The Functional Languages

A full-stack is not expected to know all but is supposed to really understand one. With the scripting languages, we have a look at the following technologies pretty sure you’ve heard of them.

Php
Node
Python
Ruby

on the functional side we have

Elixr
Erlang
Clojure
Haskell

And there’s more development patterns and technologies with relation to APIs and request-response systems.

GraphQL
Oauth
Redis
WebSockets

We also have job and task management as well as cron job management using tools like

Message Brokers
- RabbitMD
- Iron Worker
Search Systems
- Elastic Search
- Sphinx

and so much more. and it doesn't stop there, there’s DevOps to worry about.

This section deals with all factors involved in managing an application from development to deployment, this includes managing its resource system, containers and runtime environments as well as server configurations and load balancing.

So how best to describe a full-stack developer if not as someone who loves all processes involved in taking an idea from concept to launched product.

My experiment — Becoming the product developer.

In order to answer my own questions, I have decided to take on the process of building a few products from ideas and concepts for launching them. In this process, I would share my experience building each of these and possibly certify myself with a realization that full-stack developers are at their core product enthusiasts who want to see the product becoming what it is from an idea.

My process would involve a few weeks of building products — from my personal ideas taking them from concept to design, to frontend and interface implementation to functionality (backend) and deployment/testing (DevOps).

My first Idea is code named Spectre (Project Spectre) — A deployment management system for developers and teams to manage the deployment of code from the repository to the server. At the moment I'm in the process of developing the platform and I hope to release it before September. every week, I’ll document and review the process and what it means to build a product in all respect.

I hope for this to be a wonderful experience, never built an open project before but I’m willing to have the idea out there and would love to share my in-process and in-progress stats and review on who I go about implementing features.

Conclusion.

Journey to full-stack engineering is targetted to help others learn and understand that full stack development isn’t as hard as some think it to be.

My Ideas might be premature, but the intentions are focused on proving the full-stack myth. As I would always say, a javascript developer who knows frontend development and uses node (javascript on the backend) and knows how to work with Nginx and docker, can be accorded a full-stack title (there’s no diploma for these things ), but it all depends on the quality of work and knowledge.

the key is switching to a product development mindset, think of yourself as owning the idea and working with the understanding that you are looking for the best possible means of solving your problem. One step at a time.

Getting started with caddy web server

Osita Chibuike — Sat, 26 May 2018 09:57:45 +0000

The piece was originally published on my blog at legobox

Background

Last year I came across a server called caddy, I kinda liked it because it's name sounded similar to that of one of my favourite rap artiste cardi b, sounds weird right?, just kidding, that not why I loved the caddy web server, rather it was a much simpler server to install and configure than nginx, and what’s more it comes with its own integration of ssl certificates for your domains and these includes wildcards, in this article we are going to take a birds eye view of the server and get to understand why it's a great tool.

Prerequisite

There are really not much to know about, before diving into this, but it would be nice if you’ve got the following.

At least a good understanding of servers and proxying.
A general understanding of SSL - Secure Shell Layer and HTTPs

With these, you are good to go.

Origins.

Long story short caddy was created by Light Code Labs, and made open source, it operates in a similar manner to nginx with the use of server blocks, just that in this case all configurations can be done in one file called the Caddyfile, It implements https (yea emphasis on s) once its specified as part of the domain name.

Its light and lightening fast and has lots of really good documentation associated with it. Since I’ve been able to convince you (hopefully), let us have a look at how we can install and setup caddy.

Setting up caddy

First things first, you can download caddy by visiting the website (https://caddyserver.com/download), installation is pretty straightforward and easy to get on with, Most of it has been specified by their documentation, If you are looking to set up for a docker container, you might be interested in checking out this docker image.

If you downloaded the zip file, The follow these instructions to get rolling.

First, put the caddy binary in the system wide binary directory and give it appropriate ownership and permissions:

    sudo cp /path/to/caddy /usr/local/bin
    sudo chown root:root /usr/local/bin/caddy
    sudo chmod 755 /usr/local/bin/caddy

Give the caddy binary the ability to bind to privileged ports (e.g. 80, 443) as a non-root user:


    sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

Set up the user, group, and directories that will be needed:

    sudo groupadd -g 33 www-data
    sudo useradd \
      -g www-data --no-user-group \
      --home-dir /var/www --no-create-home \
      --shell /usr/sbin/nologin \
      --system --uid 33 www-data

    sudo mkdir /etc/caddy
    sudo chown -R root:www-data /etc/caddy
    sudo mkdir /etc/ssl/caddy
    sudo chown -R root:www-data /etc/ssl/caddy
    sudo chmod 0770 /etc/ssl/caddy

Place your caddy configuration in the appropriate directory and give it appropriate ownership and permissions:


    sudo cp /path/to/Caddyfile /etc/caddy/
    sudo chown www-data:www-data /etc/caddy/Caddyfile
    sudo chmod 444 /etc/caddy/Caddyfile

Create the home directory for the server and give it appropriate ownership
and permissions:


    sudo mkdir /var/www
    sudo chown www-data:www-data /var/www
    sudo chmod 555 /var/www

Let's assume you have the contents of your website in a directory called 'example.com'.
Put your website into place for it to be served by caddy:

    sudo cp -R example.com /var/www/
    sudo chown -R www-data:www-data /var/www/example.com
    sudo chmod -R 555 /var/www/example.com

You'll need to explicitly configure caddy to serve the site from this location by adding
the following to your Caddyfile if you haven't already:

    example.com {
        root /var/www/example.com
        ...
    }

Install the systemd service unit configuration file, reload the systemd daemon,
and start caddy:

    wget https://raw.githubusercontent.com/mholt/caddy/master/dist/init/linux-systemd/caddy.service
    sudo cp caddy.service /etc/systemd/system/
    sudo chown root:root /etc/systemd/system/caddy.service
    sudo chmod 644 /etc/systemd/system/caddy.service
    sudo systemctl daemon-reload
    sudo systemctl start caddy.service

Have the caddy service start automatically on boot if you like:

    sudo systemctl enable caddy.service

If caddy doesn't seem to start properly you can view the log data to help figure out what the problem is:

    journalctl --boot -u caddy.service

Use log stdout and errors stderr in your Caddyfile to fully utilize systemd journaling.

If your GNU/Linux distribution does not use journald with systemd then check any logfiles in /var/log.

If you want to follow the latest logs from caddy you can do so like this:

    journalctl -f -u caddy.service

You can make other certificates and private key files accessible to the www-data user with the following command:

    setfacl -m user:www-data:r-- /etc/ssl/private/my.key

The caddy file

While setting up you may have caught a glimpse of the caddyfile, now lets have a real look at it, how do we setup a server block, its as simple as this.

    https://mydopesite.com {
      root /path/to/site_files
    }

Voila, that simple. Let's break it down so we can understand it some more (since its so difficult)

Site Address

The HTTP server uses site addresses for labels. Addresses are specified in the form scheme://host:port/path, where all but one are optional.

The host portion is usually localhost or the domain name. The default port is 2015 (unless the site qualifies for automatic HTTPS, in which case it's changed to 443 for you). The scheme portion is another way to specify a port. Valid schemes are "http" or "https" which represent, respectively, ports 80 and 443. If both a scheme and port are specified, the port takes precedence. For example (this table assumes automatic HTTPS is applied where it qualifies):

    :2015                    # Host: (any), Port: 2015
    localhost                # Host: localhost; Port: 2015
    localhost:8080           # Host: localhost; Port: 8080
    example.com              # Host: example.com; Ports: 80->443
    http://example.com       # Host: example.com; Port: 80
    https://example.com      # Host: example.com; Ports: 80->443
    http://example.com:1234  # Host: example.com; Port: 1234

Wildcard characters * can be used in a hostname. A wildcard must take the place of an entire domain label: *.example.com is valid but foo*.example.com is not.

Path Matching.

Some directives accept an argument that specifies a base path to match. A base path is a prefix. If the URL starts with the base path, it will be a match. For example, a base path of /foo will match requests to /foo, /foo.html, /foobar, and /foo/bar.html.

Directives

Most directives invoke a layer of middleware. Middleware is a small layer in the application that handles HTTP requests and does one thing really well. Middleware are chained together (pre-compiled, if you will) at startup. Only middleware handlers which are invoked from the Caddyfile will be chained in, so small Caddyfiles are very fast and efficient.

The syntax of arguments varies from directive to directive. Some have required arguments, others don't. Consult the documentation of each directive for their signatures.

Placeholders

In some cases, directives will accept placeholders (replaceable values). These are words that are enclosed by curly braces { } and interpreted by the HTTP server at request-time. For example, {query} or {>Referer}. Think of them like variables. These placeholders have no relationship to the environment variables you can use in Caddyfiles, except we borrowed the syntax for familiarity.

If you are looking to understand some more about this, it would be wonderful to invest some time into the docs. (click here to get there)

Proxying and Load balancing in caddy

Pulling off proxy actions in caddy is as simple as setting up the proxy directive.
This middleware adds a placeholder that can be used in log formats: {upstream} - the name of the upstream host to which the request was proxied.

    https://mydomain.here{
      // usual structure is (proxy from to)
      proxy /api localhost:9005
    }

The above proxy makes all /api routes redirect to localhost:9005 (the machine’s localhost).
You can use the policy options in the proxy to set up proxying algorithm based on the same concept if the nginx algorithms.

    proxy / web1.local:80 web2.local:90 web3.local:100 {
            policy round_robin
    }

Here are the policies associated with load balancing

Policies
There are several load balancing policies available:

random (default) - Randomly select a backend
least_conn - Select backend with the fewest active connections
round_robin - Select backend in round-robin fashion
first - Select the first available backend in the order they are defined in the Caddyfile
ip_hash - Select backend by hashing the request IP, distributing evenly over the hash space based on the total number of backends
uri_hash - Select backend by hashing the request URI, distributing evenly over the hash space based on the total number of backends
header - Select by hashing the value of a given header, specified by the [value] after the policy name, distributing evenly over the hash space based on the total number of backends

Conclusion

It’s clear by now that I do love working with caddy, it's a simple tool that does the job so well, there are many options for web servers out there, but the benefits this server gives is quite exciting and worthwhile.

If you are looking to learn some more about it, feel free to check out the project on https://caddyserver.com.

My react routing structure

Osita Chibuike — Fri, 25 May 2018 10:12:40 +0000

This piece was originally posted on my blog at legobox

Background

I build frontend applications and APIs often, usually I use a variety of tools, but react has been something I find interesting, enabling me to build fast and quick, although I could argue that vue matches it word for word, but that’s not the argument of the day, enough of the react vs Vue bullshit, so I do both. They are both amazing and I’m glad there are alternatives of frameworks to choose from. In the process of developing and creating applications using react, I came up with a general structure and routing pattern for my applications.

I consider this something I’d love to share and hopefully improve with directives from the community.

Pre-requisites

To this article, there are only two pre-requisites, (last time I wrote a pre-requisite it spread like wildfire, hope it wouldn’t be asking too much for it to happen again 🙃 )

You know about react, have some experience using it.
You’ve heard of redux
You are familiar with the react router.

If you got this down?, then you are good to roll.

The Problem

The problem entails navigating between pages using the react-router library, while also keeping track of authentication status, There's already a common understanding of this problem with respect to authentication and navigation, and usually it's known that you can solve this with a simple setup of react router and redux, But there are many patterns to this very setup, in this article, I’m going to explain mine.

The Solution

In order to navigate properly in the app, I set up with react-router and implement a 3 component auth check flow, one component checks for the visitors only pages, another component checks for the protected routes, and the third component encompasses all and does a general check for the application’s auth status, I know it sounds ambiguous now, but we are going to review the code struct and get into the nitty-gritty of things.

    // import scenes here and make routes of them
    import React from 'react';
    import {Route} from 'react-router-dom';
    // import scenes here
    import {Dashboard, Settings, Login} from './Scenes'

    // auth checkers for checking if the routes are authorized
    import AppCheck from './Modules/AppCheck.jsx';
    import EnsureLoggedInContainer from './Modules/EnsureLoggedInContainer.jsx';
    import EnsureVisitorOnlyContainer from './Modules/EnsureVisitorOnlyContainer.jsx';

    const routes = (
      <React.Fragment>
            <AppCheck>
                    <EnsureVisitorOnlyContainer>
                            <Route path="/login" component={Login} />
                    </EnsureVisitorOnlyContainer>
                    <EnsureLoggedInContainer>
                            <Route exact path="/home" component={Dashboard} />
                            <Route path="/settings" component={Settings} />
                    </EnsureLoggedInContainer>
            </AppCheck>
      </React.Fragment>
    );

    export default routes;

This was drawn directly from the codebase, as you can see, the idea is clearly presented.

The three components in this case are AppCheck, EnsureVisitorOnlyContainer, EnsureLoggedInContainer.

Let’s have a look at the inner structure of these components.

AppCheck Component.


    import React from "react";
    import { connect } from "react-redux";
    import { withRouter } from "react-router";

    class AppCheck extends React.Component {

      componentDidUpdate(prevProps) {

        const { dispatch, redirectUrl } = this.props;
        const isLoggingOut = prevProps.isLoggedIn && !this.props.isLoggedIn;
        const isLoggingIn = !prevProps.isLoggedIn && this.props.isLoggedIn;

        if (isLoggingIn) {
            // dispatch(navigateTo(redirectUrl))
        } else if (isLoggingOut) {
          // do any kind of cleanup or post-logout redirection here
        }
      }

      render() {
        return this.props.children;
      }

    }

    const mapStateToProps = state => {
      console.log(state);
      return {
        isLoggedIn: state.isAuthenticated,
        redirectUrl: state.redirectUrl
      };
    };
    export default withRouter(connect(mapStateToProps)(AppCheck));

As we can see, this component checks the prop on update and confirms the state of the previous isLoggedIn status, to note if a user is logging in or logging out, depending on this, it redirects to another url specified in the redux setup, or it proceeds to logout if it's trying to log out, else it continues with the rendering of the props children.

EnsureVisitorsOnlyContainer


    import React from "react";
    import { connect } from "react-redux";
    import { withRouter } from "react-router";
    // import actions from "../Store/Actions";

    class EnsureVisitorOnlyContainer extends React.Component {

      componentDidMount() {

        const { currentURL } = this.props;
        var visitorRoutes = ["/", "", "terms", "conditions"];
        var check = visitorRoutes.indexOf(currentURL) > -1;

        if (this.props.isLoggedIn) {

          // set the current url/path for future redirection (we use a Redux action)
          // then redirect (we use a React Router method)
          //   dispatch(actions.setRedirectUrl(currentURL))
          if (check) {
            this.props.history.replace("/home");
          }
        }
      }

      render() {
        if (!this.props.isLoggedIn) {
          return this.props.children;
        } else {
          return null;
        }
      }
    }
    // Grab a reference to the current URL. If this is a web app and you are
    // using React Router, you can use `ownProps` to find the URL. Other
    // platforms (Native) or routing libraries have similar ways to find
    // the current position in the app.

    function mapStateToProps(state, ownProps) {
      console.log(ownProps);
      return {
        isLoggedIn: state.isAuthenticated,
        currentURL: ownProps.location.pathname
      };
    }
    export default withRouter(connect(mapStateToProps)(EnsureVisitorOnlyContainer));

This component set simply checks if the current route is amongst the visitors routes, if it is, then it checks the logged in status, if the app is logged in, it redirects the user to the /home route.

Any route listed in this component set would be redirected to the Home route if their path is found in the visitors list.

EnsureLoggedInContainer


    import React from 'react'
    import {connect} from 'react-redux'
    import { withRouter } from 'react-router'
    import actions from '../Store/Actions'

    class EnsureLoggedInContainer extends React.Component {

      componentDidMount() {
        const { dispatch, currentURL } = this.props
        if (!this.props.isLoggedIn) {
          // set the current url/path for future redirection (we use a Redux action)
          // then redirect (we use a React Router method)
          dispatch(actions.setRedirectUrl(currentURL))
          this.props.history.replace("/")
        }
      }

      render() {
        if (this.props.isLoggedIn) {
          return this.props.children
        } else {
          return null
        }
      }
    }
    // Grab a reference to the current URL. If this is a web app and you are
    // using React Router, you can use `ownProps` to find the URL. Other
    // platforms (Native) or routing libraries have similar ways to find
    // the current position in the app.

    function mapStateToProps(state, ownProps) {
      console.log(ownProps)
      return {
        isLoggedIn: state.isAuthenticated,
        currentURL: ownProps.location.pathname
      }
    }

    export default withRouter(connect(mapStateToProps)(EnsureLoggedInContainer))

This container checks if the current state of the app is not loggedin, it redirects to the / path, therefore all pages get to be managed via this structure.

AppCheck handling the process of logging out when the prevProp changes it's status, while EnsureVisitorsOnlyContainer and EnsureLoggedInContainer handle redirects on different instances depending on the route and within which container it's listed.

Conclusion

I am open to suggestions as to how this can be improved and to hear from you how you achieve yours, over time I hope to share other tricks and techniques I use in development with react and vue and help others learn how you can take huge advantage of the frameworks in building quicker than quick.

Understanding nginx (proxying, reverse proxying, load balancing)

Osita Chibuike — Wed, 23 May 2018 05:05:49 +0000

This piece was originally posted on my blog at legobox

Background

Many think of Nginx as just a web server, yep it's a web server, and so much more, Nginx is first and foremost a proxy engine, and load balancing server mechanism, which is capable of working as a web server using whichever post-processing interpreter you’d like, be it uWSGI, php-fpm, etc.

Many of us have heard of nginx, and some of us are looking forward to checking out what it is, in this piece we take a good look at how to use nginx as a load balancer and a general proxy passer.

Pre-requiste

Before getting up and running with nginx, it's usually important (but not compulsory) that you meet the following conditions,

You are looking to learn and understand some more DevOps
You have an understanding of what a web server is in general
You’ve used a computer before. 😏

Got all these down, then you are good to go.

Proxying

The first scenario and structure we are going to check out is the concept of proxying. In general, terms, proxying is simply having one server positioned in front of another and have all request to reach the second server through the first server.

in nginx, this is achieved using the proxy pass directive.

    // basic proxy pass
    location / {
      proxy_pass http://ourserver2here.com
    }

With the proxy pass, there are many tricks and these are important to an understanding with respect to setting a proxy pass system, let’s have a look at some of these in the books.

Matching prefixes

    location /match/here {
      proxy_pass http://ourserver2here.com;
    }

In the above setup, no URI is given at the end of the server in the proxy pass definition. In this case a request such as /match/here/please, This request would be sent to ourserver2here as https://ourserver2here/match/here/please. Pretty convenient right?

Reverse Proxying

This is one type of proxying that’s particularly interesting, It's a proxying system were by requests sent to a server (lets call it A) is actually sent to another server (lets call it B) which places in front of the first server (server A) and proceeds to relay the message to A and responds as if it's A is responding.

Here's a more formal description.

In computer networks, a reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as if they originated from the Web server itself.

Here’s a virtual description

With nginx, we could achieve this, and even take it further, ever heard of ngrok, maybe you may have, maybe not, either ways,

Ngrok is a service that allows you to serve your localhost application via a domain proxy, exposing it via a public URL.

With the reverse proxy, and setting up a subdomain on your site for such businesses, you can have your own ngrok without the constant change in the domain name and stuff.

To pull this off, the first part is to setup nginx on your server to proxy connections from your specific subdomain or domain (whichever you find convenient) to a specific port on the server.

    server {
      listen 80;

      server_name coolsubdomain.mainname.com;

      location / {
        proxy_pass http://127.0.0.1:5000; #in this case we picked the port 5000
      }
    }

on your computer, assuming our application is served on our localhost port 8000 (it could be any port really) proceeding to use ssh we run a reverse tunnel to the port on the server.

    // run a reverse proxy to your server via ssh
    ssh -R 5000:127.0.0.1:8000 youruser@mainname.com

This sets up the reverse proxy, therefore any request going to coolsubdomain.mainname.com is actually coming to your localhost machine.

Load balancing

Load balancing is another problem nginx has been uniquely positioned to solve, it’s built to handle a lot of requests and if we have several servers running our project, we can balance the load between them using upstreams.

Nginx uses upstreams to balance the load and it has a few algorithms by default which are implored to handle the load balancing mechanism.

These algorithms are specified by directives and can be noted as follows.

(round robin): The default load balancing algorithm that is used if no other balancing directives are present. Each server defined in the upstream context is passed requests sequentially in turn.
least_conn : Specifies that new connections should always be given to the backend that has the least number of active connections. This can be especially useful in situations where connections to the backend may persist for some time.
ip_hash : This balancing algorithm distributes requests to different servers based on the client's IP address. The first three octets are used as a key to deciding on the server to handle the request. The result is that clients tend to be served by the same server each time, which can assist in session consistency.
hash : This balancing algorithm is mainly used with Memcached proxying. The servers are divided based on the value of an arbitrarily provided hash key. This can be text, variables, or a combination. This is the only balancing method that requires the user to provide data, which is the key that should be used for the hash

When setting up, for load balancing it may look like this.

    # http context
    upstream backend_hosts {
      least_conn;
      server host1.example.com;
      server host2.example.com;
      server host3.example.com;
    }

    # next we set up our server
    server {
      listen 80;
      server_name example.com;
      location /proxy-me {
        proxy_pass http://backend_hosts;
      }
    }

We could even add weights to a specific host so they handle more connections in general than the rest according to a certain ratio.

    ...
    upstream backend_hosts {
      least_conn;
      server host1.example.com weight=3;
      server host2.example.com;
      server host3.example.com;
    }
    ...

Conclusion

Where are many other things we can achieve using nginx, this is pretty much just the tip of the iceberg. Setting up web servers and proxy servers can usually be a bit of a hassle, but it doesn’t have to.

In the next post under this category, I’d explore how to get this up and running using, caddy, it's a web server technology which aims to make the process of setting up web servers and proxy engines a whole lot easier.

How to setup an ethereum node

Osita Chibuike — Mon, 21 May 2018 15:34:37 +0000

This article was originally posted on my blog at legobox

What’s an ethereum node

With the advent of Bitcoin, blockchain based technologies have gradually become increasingly popular, enabling developers to build decentralized applications which many today view as the solution to a presumably problematic part of the internet, control over data.

Ethereum is unique, in that it attempts to use the same solution of the blockchain to allow anyone the ability to public dapps (decentralized apps) and have them being able to connect directly between providers and clients.

On the ethereum network every client is a node and is a part of the much larger network, therefore in setting up a client, it has to download the entire network's database and transaction readings till date. In this article, we are going to review all there is to the process of setting up an ethereum node on an Ubuntu (Linux) server.

Pre-requisites

Before jumping into configurations and commands related to setting up a node, It's important to be grounded in a few basics, therefore you should know about the following to a somewhat familiar extent.

The blockchain technology and how it works.
Managing accounts on the geth clients (thankfully we'll touch on this in the article)

Types of Nodes

There are basically two types of nodes on the network,

Lightweight nodes
Full nodes

The Lightweight nodes are meant to run on machines of lower resources and therefore keep a really shallow copy of the blockchain data, while the full node keeps track of all transactions performed on the network and therefore.

In our set up we'll review both systems so as to get a concrete understanding of how to go about the process.

Setting up a Geth Client (Node)

There are many clients for the ethereum blockchain, but the safest and well documented of them all include

Mist wallet
Geth wallet The mist wallet is a GUI (graphic user interface) based client, this enables the user to control the wallet via click and all, one can also develop contracts on the mist wallet.

Setting up a mist wallet

To set up the mist wallet, navigate to the etherum home page, then proceed to the download sections, you'll find the download button via which you can download a new version of the mist wallet.

This takes some time to setup because it has to download the blockchain's database, on completion of the download, your computer is effectively at that moment a node on the ethereum network.

Building Contracts on the mist wallet

Building contract on the mist network or the ethereum network, in general, is done in solidity, it's a strongly typed language featuring some symmetricity between C++ and javascript. on the mist wallet creating a contract is as simple as switching to the deployment section and placing your contract's code there and then proceeding to deploy. you can find a good example here.

Setting Up a Geth client wallet.

There are different ways in which one can set up a geth client, for the various operating systems there are.

Setting up for Windows

Ever heard of the Chocolatey package manager, this provides an easy way to get the required build setup and tools installed. to set up and install chocolatey checkout https://chocolatey.org.

Next, we set up the administrator command prompt and install the build tools we need.

C:\Windows\system32> choco install git
C:\Windows\system32> choco install golang
C:\Windows\system32> choco install mingw

Installing these packages will setup the path enviroment variable.

Next, let's ensure Go is installed

C:\Users\xxx> set "GOPATH=%USERPROFILE%"
C:\Users\xxx> set "Path=%USERPROFILE%\bin;%Path%"
C:\Users\xxx> setx GOPATH "%GOPATH%"
C:\Users\xxx> setx Path "%Path%"
C:\Users\xxx> mkdir src\github.com\ethereum
C:\Users\xxx> git clone https://github.com/ethereum/go-ethereum src\github.com\ethereum\go-ethereum
C:\Users\xxx> cd src\github.com\ethereum\go-ethereum
C:\Users\xxx> go get -u -v golang.org/x/net/context

Finally, the command to compile geth

C:\Users\xxx\src\github.com\ethereum\go-ethereum> go install -v ./cmd/...

With all setup, we are good to work with the setup on windows.

Setting up on Linux (Debian)

Installing from ppa

sudo apt-get install software-properties-common
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install ethereum

If you want to stay on the bleeding edge of things, install the ethereum-unstable package instead. After installing, run geth account new to create an account on your node. You should now be able to run geth and connect to the network.

There are also other options such as building from source

building from source

Build Geth ( command line client )

Clone the repository to a directory of your choosing

git clone https://github.com/ethereum/go-ethereum

Install the latest version of Go (v1.7) If you don't have it already
Building geth required Go and C compilers to be installed.

sudo apt-get install -y build-essential golang

proceed to build using the following command

cd go-ethereum
make geth

To start the node, run build/bin/geth

Setting up on Mac

The easiest way to get started with go-ethereum is to run homebrew. to install homebrew check out this

Next, add the tap and install geth

brew tap ethereum/ethereum
brew install ethereum

Managing accounts

always make sure to remember your password

On the geth, client account management is provided via the account command

$ geth account <command> [options...] [arguments...]

This lets you create new accounts, list existing accounts, import private key into a new account, migrating to new key format and changing the password.

We are going to review a few important commands to know.
creating accounts

$ geth account new
Your new account is locked with a password. Please give a password. Do not forget this password.
Passphrase:
Repeat Passphrase:
Address: {168sdunina2ee09042d83d7c5811b5334789349934}

Listing accounts

$ geth account list
Account #0: {5afdd78bdacb56ab1dad28741ea2a0e47fe41331} keystore:///tmp/mykeystore/UTC--2017-04-28T08-46-27.437847599Z--5afdd78bdacb56ab1dad28741ea2a0e47fe41331
Account #1: {9acb9ff906641a434803efb474c96a837756287f} keystore:///tmp/mykeystore/UTC--2017-04-28T08-46-52.180688336Z--9acb9ff906641a434803efb474c96a837756287f

Import private key into a node with custom datadir

$ geth account import --datadir /someOtherEthDataDir ./key.prv
The new account will be encrypted with a passphrase.
Please enter a passphrase now.
Passphrase:
Repeat Passphrase:
Address: {7f444580bfef4384839403049823453c9d}

Conclusion

Blockchain technology is still relatively new to many and there's a lot going on in that field, but getting started shouldn't have to be a problem with respect to building dapps and working with decentralized setups. In subsequent writings under this technology, I'd get into the nitty-gritty of solidity and how to go about building and deploying smart contracts.