Building Technology for Social Good, one step at a time

Last Spring, I found myself at Grainger at 1 am with a couple of peers. We met each other 10 weeks ago but have grown very comfortable with each other, sharing a Manolo’s pizza as we laughed about the embarrassing stories we told each other. We were all widely different — one of us loving hamsters and may have been an animal whisperer, one of us having an inscrutable attachment to Cheez-its, and another known for his trickery and pranks. It was 2 days before we had to demo our product to Love without Boundaries, the non-profit we were working with. The Cambodian government began testing prospective upper education students on English competency and LWB needed a way to keep track of their volunteer tutors and high school students and each of the student’s progress in learning English. We’ve already been in the basement for over 4 hours, ignoring the programming assignment we had due the next day or the midterm we had to start studying for. Instead, we were working to polish this standalone application that started from nothing 10 weeks ago.

At this point, I was wholly astonished of the dedication of my team members. Indeed, amid tests, interviews, and deprivation of sleep, this group of people deeply cared about the work we did — motivated by their desire to do good and the support of each other — and were willing to spend a tremendous amount of their own time working towards a common goal. It wasn’t anything that I ever saw, even in the myriad of student organizations that I joined that year.

Indeed, in the midst of tests, interviews, and deprivation of sleep, this group of people deeply cared about the work we did — motivated by their desire to do good and the support of each other — and were willing to spend a tremendous amount of their own time working towards a common goal.

Within this, I saw that a lot of my peers cared a lot about the community around them. A lot of us had the same questions before: How in this world full of injustices and misfortune, am I, a student, able to help my community with the engineering skillsets I am taught every day? How could I learn about the challenging issues I see and apply my skills to help tackle these issues alongside the nonprofits and experts working to do so? And even if so, was there a group of people that are equally as passionate and driven to work beside me? We all found this in Hack4Impact.

Working to build a healthier society isn’t a challenge that anyone can just wait for the right time and have the right resources and knowledge to begin pursuing. It is something that, we as students, can play a part in. At Hack4Impact, we believe the same technologies used to disrupt industries can be leveraged to empower non-profit organizations that serve people around the world. But oftentimes, after 4 years of premier education, the majority of us relocate to Silicon Valley or Seattle or New York, concentrating technical talent into geographic locations. Yet, problems are not. It is our obligation to bridge this gap, to use the skills and resources we were privileged to learn and have and work to make technology more accessible and inclusive to underserved communities. But technologies are just tools, and it’s about how we use them.

Working to build a healthier society isn’t a challenge that anyone can just wait for the right time and have the right resources and knowledge to begin pursuing. It is something that, we as students, can play a part in.

Additionally, the work we do also serves as a pedagogical opportunity for our students and breeds a passionate and tight-knit community — a family away from home.

As computer science students in a research-based university, we often find ourselves learning about theory, without the concept of users. It’s as if we are being taught writing as grammar, without mentioning that writing is a way of communicating ideas to other people. Like writing, software is a way of communicating to an audience and we emphasize this as we build products for people — to be user-centric and always going back to the user when doing so.

In addition, learning to collaborate in teams is a skill that’s learned and polished through experience. But we’ve all been there, in a class group project with a couple other students that also don’t want to be there. At least one of them doesn’t do the work they promised to do, resulting in us grudgingly picking up their work. Thus, we don’t learn to collaborate, to work together to create something greater than we alone can do. We rarely get to experience genuine teamwork in development teams made up of students; where each person is equally dedicated while leaders pursue to create an environment geared towards service and contribution. One that is more open, trusting, and giving such that new insights, learnings, and excitement are continuous as we are unified towards the same goal — to solve problems for our non-profit partners to help further their mission. Our developers learn to make Pull Requests, systematically plan out their steps to completing features, reviewing code and nonetheless grow as better teammates in longer-term projects. And most importantly, developers get to work on projects that aren’t built and thrown away in vain, but on something for real users.

However, our community makes us who we are. We work to foster a community where people are free to discuss everything from their academics to their personal life, creating meaningful relationships that last. We develop this through weekly highs and lows, banquets, retreats, org-wide assassins, cookoffs, and many more activities. Cultivating a community is our number one priority and creates a sense of engagement in the community for each of its members and establishes a sense of personal accountability while working on projects. More on this here! At the end of the day, Hack4Impact’s biggest impact is through its members because they are the ones who will continue the tech & social impact in their future careers.

At Hack4Impact, we strive to be aware of the challenges our communities are facing and give a shit about them. By prioritizing giving back, we can all make a difference. Our primary avenue of impact is through technology, but we understand technology is just a tool and isn’t always the solution to everything. But there are tremendous opportunities to work together to solve problems in the world; we each have to make the first step.

Thank you for reading! For more stories like these and updates, follow Hack4Impact UIUC on Facebook and Github.

If you’re a student at UIUC, Join Us!

Hack4Impact — A community of students that care was originally published in Hack4Impact UIUC on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reflecting on our 4th semester and our thriving community.

This was first published at https://www.notion.so/h4iuiuc. It’s a letter we write to our alumni, current and off-campus members every semester.

To our friends of Hack4Impact UIUC!

We just finished the 4th semester of our entire existence! What a wonderful milestone! When Alvin/Varun graduated and handed David and me the less than one-year-old Hack4Impact, I didn’t know whether I could live up to their footsteps. Many organizations wither away after their co-founders leave but this organization was the total opposite — it thrived, and not only did so but did so tremendously. This, I believe, was attributed to all of us and how we cared. That’s it. It’s amazing to see each person dedicated to prioritizing giving back and making an effort to help tackle the many issues in our world, giving over 10 hours/week to do so. It’s so incredible that I’m saying it because I believe it’s fully true and I actually see it.

Our Community

As a very young organization, setting a core foundation of a tight-knit community and culture was crucial. This is because once they are set in stone, it takes tremendous energy and time to enact new impactful change (initial expectations are of importance and will determine a person’s future involvement and dedication to an organization). As with all organizations, the success of Hack4Impact would come down to its people and its culture. We want to grow into empathetic and socially aware alumni and for this organization to accomplish that, we believe it all comes down to culture. Thus, this was our number one priority this semester.

As with all organizations, the success of Hack4Impact would come down to its people and its culture.

From what I’ve encountered, besides the innate desire of being understood, people not only want to do something worthwhile with their time but want to create meaningful relationships; relationships where there is mutual respect for each other’s differences while being open and supportive of each other. Collaborating with people that equally care and are willing to put in the time makes a huge difference in how each of us feels about our work. Likewise, allowing to meet people with similar interests and passions while being in an environment that facilitates bonding enables people to go beyond just “professional” relationships. In fact, a lot of members mention that the community is a huge reason for why they want to return!

I believe when teammates truly trust each other and feel safe to learn and listen to others, people then gain a sense of unity and unlock their greatest potential to grow. If I were on your team and you didn’t trust me, you may be defensive and closed off in your thoughts which isn’t collaborative at all. Thus, we might as well do separate things. But if we both trust each other, we are willing to share and understand each other’s viewpoints to generate new insights. Consequently, that trust allows for superb products and deliverables for the non-profits we work with. This was very apparent in this semester’s teams (well, previous semesters too, but the closeness of teams have been in an upward trend) where the products have been higher in quality. I find that members are more inclined to be willing to work on our products for longer together because they find a sense of ownership (which is influenced by the people around them).

But if we both trust each other, we are willing to share and understand each other’s viewpoints to generate new insights. Consequently, that trust allows for superb products and deliverables for the non-profits we work with.

So, how did we go about creating such an environment? In order for real community and relationships to materialize, members must be committed and understand that relationships take time and aren’t built out of one’s convenience. By keeping members accountable to our 8–10 hours/week we are able to put time aside, which might not always be convenient for some, to meet with other people and have fun. Instead of explaining everything in words, I’ve posted photos at the end of the letter! I’d love for you to check them out.

Obviously, we still have much to grow. Can we work to have more of an inclusive and accepting environment where underlying problems can be discussed and open? Can we have a community where each member feels safe to share about themselves and their feelings without being judged? Can each person keep each other accountable to our organizational values and our high standards instead of just the leadership doing so? This will be the next phase of our pursuit for an even stronger community.

Updates

In addition to huge strides in our community, we were able to explore a lot of new initiatives and build a solid foundation for the future of the organization. I’d like to use to section to celebrate these wins! Here are some of our firsts:

• Mass Interview Round — interviewing over 80 people in 3 hours
• External Tech Workshop for interested students.
• Sponsorship with Facebook! and building more relationships with others
• External partnerships & Local Community Engagement. Teaching multiple workshops for local high school students with WCS and at Sail.
• New Types of Projects. Data Science with Global Giving, Product Infrastructure Team building Core Services, and Product Research Team to explore how we can make more impact and measure it
• Member Spotlights & Letters like this one to keep everyone updated
• Formalization of product thought process and continuing to explore with product designers
• Exploration of different ways to give/receive feedback. Ex: 1:1s, retreat reflections, leadership surveys, multiple feedback sessions with project leads and post-mortems
• A lot more, but I’m going to bore you if I keep going

Our Teams & their Final Product Showcase Slides

• C2TC: A mobile application to help students navigate around campus more safely.
• Global Giving: Uncovering ways of characterizing the work that nonprofit organizations do all over the world, delivering Classifiers, Clusters, and Processors.
• Kiva: A web service to streamline an inefficient lending review/approval process done by Field Partners.
• Product Infrastructure: An opinionated authentication server that’s easy to integrate with our current and future products.
• Product Research: Diving deeper with our project sourcing with the goal to make more impact and measure it.

I’d also like to congratulate our new graduates — Aria Malkani, Jeffy Lin, and Nithin Rajkumar! We’ll miss you guys!

Our projects are also listed in a formal fashion on our website.

Future

Now that our community and many processes have been refined and documented, there will be a slight shift in mindset as we move towards to maximizing our impact. With a client model, it’s often hard to measure our impact and ensure the use of our products after developing it. Can we create open-sourced generalized products for more non-profits that are maintained and hosted by us? How can we be more aware and supportive of the social good sector? How might we contribute and give back to our local communities through other avenues besides technology?

Our current strategies are (this list will definitely change as time goes):

• Product Research. Having more advanced and extended project sourcing to ensure projects maximize impact and are challenging that enable developers to learn and grow. In addition, this team will spearhead more initiatives to empathize with a breadth of non-profits and the problems they are facing.
• Year-long projects instead of semester-based ones. Focusing on quality over quantity. The goal here is to have more time to do actual user research and get feedback from our MVPs, increase client buy-in & excitement, and iterate on our product.
• Handoff. Not sure here yet. But can we keep in touch with past clients and help out whenever needed? Would maintaining past projects help? If so what are ways to do so while keeping members that do so accountable and have interesting work? Etc
• Education. Mainly through programming workshops for high school students.

Final Thoughts

There will be tremendous hurdles to go through and areas of improvement to solve but I believe the tight-knit community & caring culture we’ve built together will continue to last. I have full faith that this group will grow in these situations and viscerally work towards our goal of using tech for social good. It is a hard challenge to be able to help and make a difference, but it’s worth the effort to do so. It’s not about “Why are we doing this”, it’s about “Why not”. Why not spend the time we have as students to try to help? Why not try? Why not make this a priority? It is our duty and responsibility to help serve our communities, to use the skills we learned through our premier education, and to make an effort to do so. What we do makes us who we are.

I’d like to especially thank Angad and Annie who have put in so much effort into making the organization what it is today. I’d also like to send appreciation to our Project Leads who’ve not only delivered their products but worked hard to create remarkable team environments — Josh & Aryn on Global Giving, Megha & Shreyas on C2TC, Hana & Aria on Product Infra, Arpan & Roy on Kiva, and Annie on Product Research. I’m incredibly grateful for all of you.

Leading Hack4Impact these last 2 semesters has been a very rewarding experience and I’m excited to see where Angad and Roy will take it, along with Hana leading the community and Daniel handling our external initiatives. Our work has just started.

Thank you everyone & for those on campus, I hope y’all enjoyed this past semester. Have fun this summer!

Originally published at https://www.notion.so/h4iuiuc. Our previous letter: Spring 2019 Mid-Semester Letter.

Thank you for reading! For more stories like these and updates, follow Hack4Impact UIUC on Facebook and Github. If you’re a student at the UIUC, Join Us!

Growing a new Student Organization was originally published in Hack4Impact UIUC on Medium, where people are continuing the conversation by highlighting and responding to this story.

After the entire cryptocurrency market passed 700 billion dollars in market cap, the cryptocurrency space exploded over these last couple months. But this is just the beginning. As blockchain systems continue to evolve and scale, one great way to dip into this new space and leverage this technology is with decentralized applications, otherwise known as dApps.

CryptoKitties, famous for its congestion of the Ethereum Blockchain, is a great example of a dApp, uniquely combining concepts of breedable and collectible cats with the blockchain. This sensational game is just one creative example out of a virtually unlimited number of opportunities.

Although seemingly very complicated, certain frameworks and tools have been developed to abstract your interactions with the blockchain and smart contracts. In this blog post, I will go over one way to create a decentralized voting app on Ethereum. I will briefly go over Ethereum, but you probably should have an understanding of it to use this guide to the fullest. In addition, I do expect you to know Javascript.

Why make a Decentralized Voting app?

Essentially, a great decentralized application utilizing blockchain technology allows you perform the same actions you would today (like transferring money) without a trusted third party. The best dApps have a specific real world use-case that leverages the unique characteristics of blockchain.

In essence, the blockchain is a shared, programmable, cryptographically secure and therefore trusted ledger which no single user controls and which can be inspected by anyone.- Klaus Schwab

Even though a voting app might not be a great app for consumers, I’ve chosen to use it for this guide because the main issues blockchain solves — transparency, security, accessibility, audibility — are the main problems plaguing current democratic elections.

Since a blockchain is a permanent record of transactions (votes) that are distributed, every vote can irrefutably be traced back to exactly when and where it happened without revealing the voter’s identity. In addition, past votes cannot be changed, while the present can’t be hacked, because every transaction is verified by every single node in the network. And any outside or inside attacker must have control of 51% of the nodes to alter the record.

Even if the attacker was able to achieve that while incorrectly entering user votes with their real IDs under the radar, end to end voting systems could allow voters to verify whether their vote was correctly entered in the system, making the system extremely safe.

Core Components of Ethereum

I do expect you to have an understanding of Blockchain and Ethereum for the remainder of this guide. Here is an awesome guide about it, and I’ve written a brief overview of the core components I’d like you to know.

1. Smart Contracts act as the back-end logic and storage. A contract is written in Solidity, a smart contract language, and is a collection of code and data that resides at a specific address on the Ethereum blockchain. It’s very similar to a class in Object Oriented Programming, where it includes functions and state variables. Smart Contracts, along with the Blockchain, are the basis of all Decentralized Applications. They are, like Blockchain, immutable and distributed, which means upgrading them will be a pain if they are already on the Ethereum Network. Fortunately, here are some ways to do that.
2. The Ethereum Virtual Machine(EVM) handles the internal state and computation of the entire Ethereum Network. Think of the EVM as this massive decentralized computer that contains “addresses” that are capable of executing code, changing data, and interacting with each other.
3. Web3.js is a Javascript API that allows you to interact with the Blockchain, including making transactions and calls to smart contracts. This API abstracts the communication with Ethereum Clients, allowing developers to focus on the content of their application. You must have a web3 instance imbedded in your browser to do so.

Other Tools we will use

1. Truffle is a popular testing development framework for Ethereum. It includes a development blockchain, compilation and migration scripts to deploy your contract to the Blockchain, contract testing, and so on. It makes development easier!
2. Truffle Contracts is an abstraction on top of the Web3 Javascript API, allowing you to easily connect and interact with your Smart Contract.
3. Metamask brings Ethereum to your browser. It is a browser extension that provides a secure web3 instance linked to your Ethereum address, allowing you to use Decentralized Applications. We will not be using Metamask in this tutorial, but it is a way for people to interact with your DApp in production. Instead, we will inject our own web3 instance during development. For more information, check out this link.

Let’s Start!

For simplicity, we actually won’t be building the full voting system I described earlier. For ease of explanation, it will just be a one page application where a user can enter their ID and vote for a candidate. There will also be a button that counts and displays the number of votes per candidate.

This way, we will be able to focus the process of creating and interacting with the smart contracts within an application. The source code for this entire application will be in this repository, and you will need to have Node.js and npm installed.

First, let’s install Truffle globally.

npm install -g truffle

To use Truffle commands, you must run them in an existing project.

git clone https://github.com/tko22/truffle-webpack-boilerplate
cd truffle-webpack-boilerplate
npm install

This repository is just a skeleton of a Truffle Box, which are boilerplates or example applications that you can get in one command — truffle unbox [box name]. However, the Truffle box with webpack isn’t updated with the latest versions and includes an example application. Thus, I created this repo (the one linked in the instructions above).

2. Directory Structure

Your directory structure should include these:

• contracts/ — Folder holding all of the Contracts. DO NOT DELETE Migrations.sol
• migrations/ — Folder holding Migration files, which help you deploy your smart contracts into the Blockchain.
• src/ — holds the HTML/CSS and Javascript files for the application
• truffle.js — Truffle Configuration file
• build/ — You won’t see this folder until you compile your contracts. This folder holds the build artifacts so don’t modify any of these files! Build artifacts describe the function and architecture of your contract and give Truffle Contracts and web3 information on how to interact with your Smart Contract in the Blockchain.

1. Write your Smart Contracts

Enough with the setup and introduction. Let’s get into the code! First off, we’ll be writing our Smart Contract, which is written in Solidity (the other languages aren’t as popular). It may seem scary, but it’s not.

For any application, you want your smart contracts to be as simple as possible, even stupidly simple. Remember that you have to pay for every computation/transaction you make, and your smart contracts will be on the Blockchain forever. So, you really want it to work perfectly––meaning, the more complex it is, the easier it is to make a mistake.

Our contract will include:

1. State Variables — variables that hold values that are permanently stored on the Blockchain. We will use state variables to hold a list and number of Voters and Candidates.
2. Functions — Functions are the executables of smart contracts. They are what we will call to interact with the Blockchain, and they have different levels of visibility, internally and externally. Keep in mind that whenever you want to change the value/state of a variable, a transaction must occur — costing Ether. You can also make calls to the Blockchain, which won’t cost any Ether because the changes you made will be destroyed (more on this in Section 3 when we actually make the transactions and calls).
3. Events — Whenever an event is called, the value passed into the event will be logged in the transaction’s log. This allows Javascript callback functions or resolved promises to view the certain value you wanted to pass back after a transaction. This is because every time you make a transaction, a transaction log will be returned. We will use an event to log the ID of the newly created Candidate, which we’ll display (check the first bullet point of Section 3).
4. Struct Types — This is very similar to a C struct. Structs allow you to hold multiple variables, and are awesome for things with multiple attributes. Candidates will only have their name and party, but you can definitely add more attributes to them.
5. Mappings — Think of these like hash-maps or dictionaries, where it has a key-value pair. We will use two mappings.

There are a couple more types that aren’t listed here, but some of them are a little more complicated. These five encompass many of the structures a smart contract will generally use. These types are explained more in depth here.

For reference, here’s the Smart Contract’s code. Note that this file should be called Voting.sol but I wanted the Github gist to have styling so I gave it a .js extension. Like the rest of this guide, I will provide comments within the code that will explain what it is doing, and I’ll explain the big picture afterwards while pointing out certain caveats and logic.

Basically, we have two Structs (types that hold multiple variables) that describe a Voter and a Candidate. With Structs, we are able to assign multiple properties to them, such as emails, address, and so on.

To keep track of Voters and Candidates, we put them into separate mappings where they are integer indexed. A Candidate or Voter’s index/key––lets call it ID — is the sole way for functions to access them.

We also keep track of the number of Voters and Candidates, which will help us index them. In addition, don’t forget about the event in line 8, which will log the candidate’s ID when it’s added. This event will be used by our interface, since we need to keep track of a candidate’s ID in order to vote for a candidate.

1. I know, contrary to what I said earlier about making contracts super simple, I made this contract a little more complicated in comparison to what this application actually does. However, I did this so that it would be a lot easier for you guys to make edits and add features to this application afterward (more on that at the end). If you’d like to make an even simpler voting application, the smart contract could work in less than 15 lines of code.
2. Note that the state variables numCandidates and numVoters are not declared public. By default, these variables have a visibility of internal, which means that they can only be directly accessed by the current contract or derived contracts (don’t worry about that, we won’t be using it).
3. We are using 32bytes for strings instead of using the string type. Our EVM has a word-size of 32 bytes, so it is “optimized” for dealing with data in chunks of 32 bytes. (Compilers, such as Solidity, have to do more work and generate more bytecode when data isn’t in chunks of 32 bytes, which effectively leads to higher gas cost.)
4. When a user votes, a new Voter struct is created and added to the mapping. In order to count the number of votes a certain candidate has, you must loop through all the Voters and count the number of votes. Candidates operate on the same behavior. Thus, these mappings will hold the history of all Candidates and Voters.

2. Instantiate web3 and contracts

With our Smart Contract completed, we now need to run our test blockchain and deploy this contract onto the Blockchain. We’ll also need a way to talk to it, which will be via web3.js.

Before we start our test blockchain, we must create a file called 2_deploy_contracts.js inside the folder /contracts that tells it to include your Voting Smart Contract when you migrate.

To start the development Ethereum blockchain, go to your command line and run:

truffle develop

This will live on your command line. Since Solidity is a compiled language, we must compile it to bytecode first for the EVM to execute.

compile

You should see a build/ folder inside your directory now. This folder holds the build artifacts, which are critical to the inner workings of Truffle, so don’t touch them!

Next, we must migrate the contract. Migrations is a Truffle script that helps you alter the state of your application’s contract as you develop. Remember that your contract is deployed to a certain address on the Blockchain, so whenever you make changes, your contract will be located at a different address. Migrations help you do this and also help you move data around.

migrate

Congratulations! Your smart contract is now on the Blockchain forever. Well, not really…. because truffle develop refreshes every time you stop it.

If you’d like to have a persisting blockchain, consider Ganache, which is also developed by Truffle. If you are using Ganache, you will not need to call truffle develop. Instead, you will run truffle compile and truffle migrate. To understand what it really takes to deploy a contract without Truffle, check out this blog post.

Once we have deployed the smart contract to the Blockchain, we will have to setup a web3.0 instance with Javascript on the browser whenever the application starts. Thus, the next piece of code will be placed in the bottom of js/app.js. Note that we are using web3.0 version 0.20.1.

You don’t really have to worry too much if you don’t understand this code. Just know that this will be run when the application starts and will check if there already is a web3 instance (Metamask) in your browser. If there isn’t, we’ll just create one that talks to localhost:9545, which is the Truffle development blockchain.

If you’re using Ganache, you must change the port to 7545. Once an instance is created, we will call the start function (I’ll define it in the next section).

3. Add functionality

The last thing we’ll need to do is to write the interface for the application. This involves the essentials for any web application––HTML, CSS, and Javascript (We’ve already written a little of the Javascript with creating a web3 instance). First, let’s create our HTML file.

This is a very simple page, with an input form for user ID, and buttons for Voting and Counting votes. When those buttons are clicked, they will call specific functions that vote, and will find the number of votes for the candidates.

There are three important div elements though, with ids: candidate-box, msg, and vote-box, which will hold checkboxes for each candidate, a message, and the number of votes, respectively. We also import JQuery, Bootstrap, and app.js.

Now, we just need to interact with the Contract and implement the functions for voting and counting the number of votes for each candidate. JQuery will manipulate the DOM, and we’ll be using Promises as we make transactions or calls to the Blockchain. Below is the code for app.js.

Note that the code I provided in the previous step for creating a web3 instance is also here. First, we import the necessary libraries and webpack stuff, including web3 and Truffle Contracts. We will be using Truffle Contracts, which is built on top of web3 to interact with the Blockchain.

To use it, we’ll grab the build artifacts that were automatically built when we compiled the voting smart contract and use them to create the Truffle Contract. Finally, we set up the functions in the global variable window for starting the app, voting for a candidate, and finding the number of votes.

To actually interact with the Blockchain, we must create an instance of the Truffle Contract by using the deployed function. This, in turn, will return a promise with the instance as the return value that you will use to call functions from the smart contract.

There are two ways to interact with those functions: transactions and calls. A transaction is a write-operation, and it will be broadcast to the entire network and processed by miners (and thus, costs Ether). You must perform a transaction if you’re changing a state variable, since it will change the state of the blockchain.

A call is a read-operation, simulating a transaction but discarding the change in state. Thus, it will not cost Ether. This is great for calling getter functions (check out the four getter functions we wrote previously in our smart contract).

To make a transaction with Truffle Contracts, you write instance.functionName(param1, param2), with instance as the instance that was returned by the deployed function (Check line 36 for an example). This transaction will return a promise with the transaction data as the return value. Thus, if you return a value in your smart contract function but you perform a transaction with that same function, it will not return that value.

This is why we have an event that will log whatever you want it to write into the transaction data that will be returned. In the case of lines 36–37, we make a transaction to add a Candidate. When we resolve the promise, we have the transaction data in result.

To get the candidateID that we logged with the event AddedCandidate() (check the smart contract to see it 0), we must go through the logs and retrieve it like this: result.logs[0].args.candidateID.

To really see what’s going on, use the Chrome developer tools to print out the result and look through its structure of result.

To make a call, you will write instance.functionName.call(param1,param2). However, if a function has the keyword view, then Truffle Contracts will automatically create a call and thus you don’t need to add the .call.

This is why our getter functions have the view keyword. Unlike making a transaction, the returned promise of a call will have a return value of whatever is returned by the smart contract function.

I will now explain the 3 functions briefly but this should be very familiar if you’ve built applications retrieving/changing data from a data store and manipulating the DOM accordingly. Think of the Blockchain as your database, and the Truffle Contracts as the API to get data from your database.

App.start()

This function is called immediately after we create a web3 instance. To get Truffle Contracts to work, we must set the provider to the created web3 instance and set defaults (like which account you’re using and the amount of gas you want to pay to make a transaction).

Since we are in development mode, we can use any amount of gas and any account. During production, we would take the account provided by MetaMask and try to figure out the smallest amount of gas you could use, since it’s actually real money.

With everything set up, we will now display the checkboxes for each candidate for the user to vote. To do this, we must create an instance of the contract and get the Candidate’s information. If there aren’t any candidates, we will create them. In order for a user to vote for a candidate, we must provide the ID of that certain candidate. Thus, we make each checkbox element have an id(HTML element attribute) of the ID of the candidate. Additionally, we will add the number Of candidates to a global variable numOfCandidates, which we will use in App.findNumOfVotes(). JQuery is used to append each checkbox and its candidate name to .candidate-box.

App.vote()

This function will vote for a certain candidate based on which checkbox is clicked and its id attribute.

One, we will check whether the user has input their userID, which is their identification. If they didn’t, we display a message telling them to do so.

Two, we will check whether the user is voting for a candidate, checking if there is at least one checkbox that’s clicked. If none of the checkboxes were clicked, we will also display a message telling them to vote for a candidate. If one of the checkboxes is clicked, we will grab the id attribute of that checkbox, which is also the linked candidate’s ID, and use that to vote for the candidate.

Once the transaction has been completed, we will resolve the returned promise and display a “Voted” message.

App.findNumOfVotes()

This last function will find the number of Votes for each candidate and display them. We will go through the candidates and call two smart contract functions, getCandidate and totalVotes. We will resolve those promises and create an HTML element for that certain candidate.

Now, start the application and you’ll see it on http://localhost:8080/!

npm run dev

Resources

I know, it’s a lot… You might have this article open for a while as you slowly develop this application and really understand what’s going on. But that’s learning! Please supplement this guide with all the documentation from Ethereum, Truffle, and what I have provided below. I’ve tried to hit many of the key points in this article, but it’s just a brief overview and these resources will help a lot.

• Everything about Solidity and Smart Contracts — I mean Everything
• Everything about Truffle
• Truffle Contracts Docs
• Web3 Javascript API — this will be great to know and reference, but Truffle Contracts abstracts many parts of this
• Useful DApp patterns
• Ethereum Docs — look to the side bar and there’s plenty of stuff
• CryptoKitties Code Explanation — The writer goes through the important parts of CryptoKitties’ Smart Contract
• Smart Contract Best Practices — a must read

Conclusion

Building applications on Ethereum is pretty similar to a regular application calling a backend service. The hardest part is writing a robust and complete smart contract. I hope this guide helped you understand the core knowledge of decentralized applications and Ethereum and will help you kick-start your interest in developing them.

If you’d like to build off of what we’ve built, here are some ideas. I’ve actually written the smart contract in such a way that it’s easily implemented with everything I’ve given you in this guide.

• Display the party of each Candidate. We already get the party of a candidate when we run getCandidate(id).
• Check if the User-entered ID is unique.
• Ask and store more information about a User, such as their date of birth and home address.
• Add in an option to see whether a person with a specific id has voted or not. You would create a new form to enter in an ID, which you would then search for that certain user in the blockchain.
• Write a new smart contract function that counts the votes for BOTH candidates at once. Currently, we have to make two separate calls for two candidates, requiring the contract to loop through all the Users twice.
• Allow new Candidates to be added. This means adding a new form to add Candidates, but also changing up a little on how we display and vote for candidates in the frontend.
• Require Users to have an Ethereum Address to vote. My logic for not including user addresses is because voters wouldn’t be expected to have Ethereum to participate in this voting process. However, many DApps will require users to have an Ethereum Address.

Also, here are some tips that could prevent some roadblocks from happening:

• Double and triple check your smart contract functions when something weird is happening. I spent a couple hours on a bug to figure out that I returned the wrong value in one of my functions.
• Check whether your URL and port are correct when you connect to your development blockchain. Remember: 7545 is for truffle develop and 9545 is for Ganache. These are defaults, so if you can’t connect to your blockchain, you might’ve changed them.
• I didn’t go over this because this guide would’ve been too long and I probably will make another post on this — but you should test your contracts! It will help a lot.
• If you aren’t familiar with promises, go through how they work and how to use them. Truffle Contracts uses promises and the beta for web3 will also support promises. They can, if you do them wrong, mess up a lot of the data you’re retrieving.

Cheers to working towards a decentralized and secure internet — Web 3.0!

I hope you enjoyed reading this guide as much as I enjoyed writing it! If you have any thoughts and comments, feel free to leave a comment below or email me at tk2@illinois.edu or tweet me( I’ve recently created one)! Feel free to use my code and share it with your friends!

A guide to developing an Ethereum decentralized voting application was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Docker, one of the latest crazes, is an amazing and powerful tool for packing, shipping, and running applications. However, understanding and setting up Docker for your specific application can take a bit of time. Since the internet is filled with conceptual guides, I won’t be going too deep conceptually about Containers. Instead, I’ll be explaining what each line I write means and how you can apply that to your specific application and configuration.

Why Docker?

I am part of a student-run non-profit called Hack4Impact at UIUC, where we develop technical projects for non-profit organizations to help them further their missions. Each semester, we have multiple project teams of 5–7 student software developers, with a variety of skill levels including students who have only finished their first college-level computer science course.

Since many non-profits often asked for web applications, I curated a Flask Boilerplate to allow teams to quickly get their backend REST API services up and running. Common utility functions, application structure, database wrappers, and connections are all provided along with documentation for setup, best coding practices, and steps for Heroku deployment.

Issues with Development Environment and Dependencies

However, since we onboard new student software developers every semester, teams would spend a lot of time configuring and troubleshooting environment issues. We would often have multiple members developing on different Operating Systems and ran into a myriad of problems(Windows, I’m pointing at you). Although many of those problems were trivial, such as starting up the correct PostgreSQL database version with the right user/password, it wasted time that could’ve been put into the product itself.

In addition to that, I only wrote documentation for MacOS users with only bash instructions (I have a Mac), and essentially left Windows and Linux users out to dry. I could’ve spun up some Virtual Machines and documented the setup again for each OS, but why would I do that if there’s Docker?

Enter Docker

With Docker, the entire application can be isolated in containers that can be ported from machine to machine. This allows for consistent environments and dependencies. Thus, you can “build once, run anywhere,” and developers will now be able to install just one thing — Docker — and run a couple commands to get the application running. Newcomers will be able to rapidly begin developing without worrying about their environment. Nonprofits will also be able to quickly make changes in the future.

Docker also has many other benefits, such as its portable and resource-efficient nature (compared to Virtual Machines), and how you can painlessly set up Continuous Integration and rapidly deploy your application.

A Brief Overview of Docker Core Components

There are many resources online that will explain Docker better than I can, so I won’t go over them in too much detail. Here’s an awesome blog post on its concepts, and another one on Docker specifically. I will, however, go over some of the Core Components of Docker that are required to understand the rest of this blog post.

Docker Images

Docker images are read-only templates that describe a Docker Container. They include specific instructions written in a Dockerfile that defines the application and its dependencies. Think of them as a snapshot of your application at a certain time. You will get images when you docker build.

Docker Containers

Docker Containers are instances of Docker images. They include the operating system, application code, runtime, system tools, system libraries, and so on. You are able to connect multiple Docker Containers together, such as a having a Node.js application in one container that is connected to a Redis database container. You will run a Docker Container with docker start.

Docker Registries

A Docker Registry is a place for you to store and distribute Docker images. We will be using Docker Images as our base images from DockerHub, a free registry hosted by Docker itself.

Docker Compose

Docker Compose is a tool that allows you to build and start multiple Docker Images at once. Instead of running the same multiple commands every time you want to start your application, you can do them all in one command — once you provide a specific configuration.

Docker example with Flask and Postgres

With all the Docker components in mind, let’s get into setting up a Docker Development environment with Flask Application using Postgres as its data store. For the remainder of this blog post, I will be referencing Flask Boilerplate, the repository I mentioned earlier for Hack4Impact.

In this configuration, we will use Docker to build two Images:

• app — the Flask Application served in port 5000
• postgres — the Postgres Database served in port 5432

When you look at the top directory, there are three files that define this configuration:

• Dockerfile — a script composed of instructions to setup the app containers. Each command is automatic and is successively performed. This file will be located in the directory where you run the app(python manage.py runserver or python app.py or npm start are some examples). In our case, it is in the top directory(where manage.py is located). A Dockerfile accepts Docker Instructions.
• .dockerignore — specifies which files not to include in the Container. It is just like .gitignore but for the Docker Containers. This file is paired with the Dockerfile.
• docker-compose.yml — Configuration file for Docker Compose. This will allow us to build both app and postgres images at once, define volumes and state that app depends on postgres, and set required environmental variables.

Note: There’s only one Dockerfile for two images because we will be taking an official Docker Postgres image from DockerHub! You can include your own Postgres Image by writing your own Dockerfile for it, but there’s no point.

Dockerfile

Just to clarify again, this Dockerfile is for the app container. As an overview, here is the entire Dockerfile—it essentially gets a base image, copies the application over, installs dependencies, and sets a specific environment variable.

FROM python:3.6

LABEL maintainer "Timothy Ko <tk2@illinois.edu>"

RUN apt-get update

RUN mkdir /app

WORKDIR /app

COPY . /app

RUN pip install --no-cache-dir -r requirements.txt

ENV FLASK_ENV="docker"

EXPOSE 5000

Because this Flask Application uses Python 3.6, we want an environment that supports it and already has it installed. Fortunately, DockerHub has an official image that’s installed on top of Ubuntu. In one line, we will have a base Ubuntu image with Python 3.6, virtualenv, and pip. There are tons of images on DockerHub, but if you would like to start off with a fresh Ubuntu image and build on top of it, you could do that.

FROM python:3.6

I then note that I’m the maintainer.

LABEL maintainer "Timothy Ko <tk2@illinois.edu>"

Now it’s time to add the Flask application to the image. For simplicity, I decided to copy the application under the /app directory on our Docker Image.

RUN mkdir /app

COPY . /app

WORKDIR /app

WORKDIR is essentially a cd in bash, and COPY copies a certain directory to the provided directory in an image. ADD is another command that does the same thing as COPY , but it also allows you to add a repository from a URL. Thus, if you want to clone your git repository instead of copying it from your local repository (for staging and production purposes), you can use that. COPY, however, should be used most of the time unless you have a URL. Every time you use RUN, COPY, FROM, or CMD, you create a new layer in your docker image, which affects the way Docker stores and caches images. For more information on best practices and layering, see Dockerfile Best Practices.

Now that we have our repository copied to the image, we will install all of our dependencies, which is defined in requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

But say you had a Node application instead of Flask — you would instead write RUN npm install. The next step is to tell Flask to use Docker Configurations that I hardcoded into config.py. In that configuration, Flask will connect to the correct database we will set up later on. Since I had production and regular development configurations, I made it so that Flask would choose the Docker Configuration whenever the FLASK_ENV environment variable is set to docker. So, we need to set that up in our app image.

ENV FLASK_ENV="docker"

Then, expose the port(5000) the Flask application runs on:

EXPOSE 5000

And that’s it! So no matter what OS you’re on, or how bad you are at following documentation instructions, your Docker image will be same as your team members’ because of this Dockerfile.

Anytime you build your image, these following commands will be run. You can now build this image with sudo docker build -t app .. However, when you run it with sudo docker run app to start a Docker Container, the application will run into a database connection error. This is is because you haven’t provisioned a database yet.

docker-compose.yml

Docker Compose will allow you to do that and build your app image at the same time. The entire file looks like this:

version: '2.1'
services:
  postgres:
    restart: always
    image: postgres:10
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}
    volumes:
      - ./postgres-data/postgres:/var/lib/postgresql/data
    ports:
      - "5432:5432"
  app:
    restart: always
    build: .
    ports:
      - 5000:5000
    volumes:
      - .:/app

For this specific repository, I decided to use version 2.1 since I was more comfortable with it and it had a few more guides and tutorials on it — yeah, that’s my only reasoning for not using version 3. With version 2, you must provide “services” or images you want to include. In our case, it is app and postgres(these are just names that you can refer to when you use docker-compose commands. You call them database and api or whatever floats your boat).

Postgres Image

Looking at the Postgres Service, I specify that it is a postgres:10 image, which is another DockerHub Image. This image is an Ubuntu Image that has Postgres installed and will automatically start the Postgres server.

postgres:
  restart: always
  image: postgres:10
  environment:
    - POSTGRES_USER=${USER}
    - POSTGRES_PASSWORD=${PASSWORD}
    - POSTGRES_DB=${DB}
  volumes:
    - ./postgres-data/postgres:/var/lib/postgresql/data
  ports:
    - "5432:5432"

If you want a different version, just change the “10” to something else. To specify what user, password, and database you want inside Postgres, you have to define environment variables beforehand — this is implemented in the official postgres Docker image’s Dockerfile. In this case, the postgres image will inject the $USER, $PASSWORD, and $DB environment variables and make them the POSTGRES_USER, POSTGRES_PASSWORD, and POSTGRES_DB envrionment variables inside the postgres container. Note that $USER and the other environment variables injected are environment variables specified in your own computer (more specifically the command line process you are using to run the docker-compose up command. By injecting your credentials, this allows you to not commit your credentials into a public repository.

Docker-compose will also automatically inject environment variables if you have a .env file in the same directory as your docker-compose.yml file. Here’s an example of a .env file for this scenario:

USER=testusr
PASSWORD=password
DB=testdb

Thus our PostgreSQL database will be named testdb with a user called testusr with password password.

Our Flask application will connect to this specific database, because I wrote down its URL in the Docker Configurations I mentioned earlier.

Every time a container is stopped and removed, the data is deleted. Thus, you must provide a persistent data storage so none of the database data is deleted. There are two ways to do it:

• Docker Volumes
• Local Directory Mounts

I’ve chosen to mount it locally to ./postgres-data/postgres , but it can be anywhere. The syntax is always[HOST]:[CONTAINER]. This means any data from /var/lib/postgresql/data is actually stored in ./postgres-data.

volumes:
- ./postgres-data/postgres:/var/lib/postgresql/data

We will use the same syntax for ports:

ports:
- "5432:5432"

app Image

We will then define the app image.

app:
  restart: always
  build: .
  ports:
    - 5000:5000
  volumes: 
    - .:/app
  depends_on:
    - postgres
  entrypoint: ["python", "manage.py","runserver"]

We first define it to have restart: always. This means that it will restart whenever it fails. This is especially useful when we build and start these containers. app will generally start up before postgres, meaning that app will try to connect to the database and fail, since the postgres isn’t up yet. Without this property, app would just stop and that’s the end of it.

We then define that we want this build to be the Dockerfile that is in this current directory:

build: .

This next step is pretty important for the Flask server to restart whenever you change any code in your local repository. This is very helpful so you don’t need to rebuild your image over and over again every time to see your changes. To do this, we do the same thing we did for postgres : we state that the /app directory inside the container will be whatever is in .(the current directory). Thus, any changes in your local repo will be reflected inside the container.

volumes:
  - .:/app

After this, we need to tell Docker Compose that app depends on the postgres container. Note that if you change the name of the image to something else like database, you must replace that postgres with that name.

depends_on:
  - postgres

Finally, we need to provide the command that is called to start our application. In our case, it’s python manage.py runserver.

entrypoint: ["python", "manage.py","runserver"]

One caveat for Flask is that you must explicitly note which host (port) you want to run it in, and whether you want it to be in debug mode when you run it. So in manage.py, I do that with:

def runserver():
    app.run(debug=True, host=’0.0.0.0', port=5000)

Finally, build and start your Flask app and Postgres Database using your Command Line:

docker-compose build
docker-compose up -d
docker-compose exec app python manage.py recreate_db

The last command essentially creates the database schema defined by my Flask app in Postgres.

And that’s it! You should be able to see the Flask application running on http://localhost:5000!

Docker Commands

Remembering and finding Docker commands can be pretty frustrating in the beginning, so here’s a list of them! I’ve also written a bunch of commonly used ones in my Flask Boilerplate Docs if you want to refer to that.

Conclusion

Docker truly allows teams to develop much faster with its portability and consistent environments across platforms. Although I’ve only gone through using Docker for development, Docker excels when you use it for Continuous Integration/testing and in Deployment.

I could add a couple more lines and have a full production setup with Nginx and Gunicorn. If I wanted to use Redis for session caching or as a queue, I could do that very quickly and everyone on my team would be able to have the same environment when they rebuilt their Docker Images.

Not only that, I could spin up 20 instances of the Flask Application in seconds if I wanted to. Thanks for reading! :)

If you have any thoughts and comments, feel free to leave a comment below or email me at tk2@illinois.edu! Also, feel free to use my code or share this with your peers!

Docker Development WorkFlow — a guide with Flask and Postgres was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Like me, you’ve probably developed a Django or Flask app before and have used their templating but you want to use the new hot front-end javascript library called React. But how in the hell can you connect these two together… And since I didn’t have much knowledge on frontend and backend frameworks, I was lost. There aren’t that much documentation on Django/Flask and React so hopefully this can fill in the gap and confusion that I felt a couple months ago.

Your options

• Using Django/Flask to create a REST API and having React to consume the API by making HTTP requests to it.
• Using Webpack (module bundler) and Babel (transpiler) to bundle up your React files and link them in your HTML file. This will not use Django’s templating but instead use React. Some tutorials on this are here and here.

Consuming a Python REST API with React

Essentially, the Django or Flask application will entirely be separate from your React app. You will run Django, and then run React, which will connect to Django through HTTP Requests. However, for this to work, you must know what a REST API is and how you can implement one. I actually wrote a post about this, but in short, a REST API has endpoints such as /users that will return text(information related to the name of the endpoint), and React will make HTTP Requests that will get the text and display it in a certain way. The text will most likely be in JSON format. Think about going to a webpage with just text displayed, and thats it.

How does React make HTTP Requests?

In Javascript, there are different ways of making HTTP Requests: JQuery $.ajax, Fetch, Axios, Superagent, and many more! I would recommend the Fetch API, since it is standardized and uses Promises! Essentially, you would use Fetch to make an HTTP request to a certain endpoint like https://api.yourdomain.com/users, get the JSON text, and return a Promise object, which wraps around the JSON text. You will then pass the data inside the Promise to your React Components, who will display them.

How do you implement a REST API using Django/Flask?

For Django, a great way and easy way is to use the Django REST Framework. This Django Package provides you with general functions that you would generally use to create an API such as serialization and authentication. Please understand what a REST API is before you jump into this. For Flask, there is a library called Flask API that is pretty much the same as the Django REST Framework. Note that these packages are just used to help and guide you to create an API. You can just create URL endpoints(in views.py for Django) and write out the functionality and return a JSON text.

What would it look like in Development?

So, for Django, you would run your API aka your application like you normally do with:

$ python manage.py runserver

Then, assuming that you are using create-react-app(You really should be), you run your React app normally with:

$ npm run start

To make HTTP requests, you will use the fetch API to make requests to your Django app that is directed, by default, to http://localhost:8000/.

What would it look like in Production?

They are separate applications! Since a React app is static(think HTML/CSS/JS files), you can use Amazon’s AWS S3, Heroku, or Now to deploy the app. You would have yourdomain.com pointed to that server. Then, you would use AWS, Heroku, Google Cloud, Digital Ocean to serve your API . aka your Django app like you would normally do. Another domain such as api.yourdomain.com could be pointed to the server serving your API. Your React app will then make HTTP requests to api.yourdomain.com! If you don’t want to pay for two services, you can put both applications in the same server and use a reverse proxy(e.g. Nginx) and use that to serve React files and your Django app. Here’s a previous a post I wrote on deploying React with Nginx!

Resources

I know this may be a lot of information and jargon to take in, especially if you are just starting to learn about Web Development. Here is a list of technologies you should know about that will definitely help you better understand what is going on!

• HTTP Requests
• REST API
• JSON
• URL endpoints
• Client-Server Model

This post is also very useful to understanding Web Development! There are plenty of guides on topics like implementing an API using Django and how to deploy a Django app or React app and I believe they would be more helpful to you than if I were to rewrite one. But hopefully, this gives you an overall picture of what is happening allow you to move on to actually developing applications instead of wondering how everything works together!

I hope this guide helped solve a headache of yours! I’m pretty new at this and I’d like to get better — any response is welcome :)

Check out my other posts and tutorials!

Timothy Ko - Medium

Working with C++ libraries on a Mac can be a pain and OpenSSL, a very popular one that’s used in many other libraries, led me scrambling around the web and going through different StackOverflow posts, Github issues, and blog posts/forums trying to figure out a way to do it without reinstalling everything.

Usually, you would just install OpenSSL with Homebrew….

$ brew install openssl

And then link it…

$ brew link --force openssl
Warning: Refusing to link: openssl
Linking keg-only openssl means you may end up linking against the insecure, 
deprecated system OpenSSL while using the headers from Homebrew's openssl.
Instead, pass the full include/library paths to your compiler e.g.:
   -I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib

But don’t worry! There’s a fix. Homebrew installs OpenSSL but doesn’t link it to /usr/local/include, where the compiler looks into during #include< …> Thus, you must manually link it instead:

$ ln -s /usr/local/opt/openssl/include/openssl /usr/local/include

You also might want to link:

$ ln -s /usr/local/Cellar/openssl/[version]/include/openssl /usr/bin/openssl
$ ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/

An example of [version] is 1.0.2j. And just in case, check whether you compiler looks into /usr/local/include. For clang, it is:

clang -x c -v -E /dev/null

And it should output this if clang searches through /usr/local/include

#include <...> search starts here:
/usr/local/include

And you should be able to start using OpenSSL! This fix also doesn’t just work with your C++ project but any project(e.g. Ruby project) you are building that uses OpenSSL.

And just a reminder — remember to add -lssl and -lcrypto flags for your compiler.

I hope this guide helped solve a headache of yours! I’m pretty new at this and I’d like to get better — any response is welcome :)

Check out my other posts and tutorials!

Timothy Ko - Medium

The technologies we will use are:

• Nginx: Lightweight and high performance Web server or Reverse Proxy. It is mainly used to act as a reverse proxy to quickly serve static files and send requests to proxied web servers or act as a load balancer.
• Ubuntu 16.04: A very popular Linux Distro. Version 16.04 is the latest Long Term Support Version and will be until 2021.
• DigitalOcean: A Cloud Infrastructure Company that allows you to create a droplet/server in the “cloud”. It starts off at $5/month, making it very affordable.

First off, follow this tutorial made by DigitalOcean themselves about setting up an Ubuntu server. I’m not going over it because it should be pretty simple — creating an account, a couple button clicks, and boom you have a server in the “cloud”! Isn’t that awesome? Any Cloud service that allows to deploy a server, such as Amazon AWS or Google Cloud would also work. Also, if you would like to add a domain pointing to your server, check out this.

Now that you have setup your Ubuntu machine, SSH into it and update!

sudo apt-get update

Install Node.js & npm

I like using the Current Stable version of Node.js, which is currently in version 8, but if you want to install a different version you can change the 8 to whatever version you’d like.

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs 

What setup_8.x does is check whether your operating system version is supported and adds the correct repository. This command also installs npm so you don’t have to worry about that.

Clone your repository on your machine

I have been using the LAMP stack for a while so I like putting my web app files in /var/www/.

sudo mkdir /var/www
cd /var/www/

However, if you prefer another place to put them, you can do that. Another common place is in /www/.

sudo mkdir /www 
cd /www

Since you wouldn’t want to use sudo every time you interact with files in /var/www or /www, let’s give your user privileges to these folders. Constantly using sudo increases the chances of accidentally trashing your system.

sudo gpasswd -a "$USER" www-data
sudo chown -R "$USER":www-data /var/www
find /var/www -type f -exec chmod 0660 {} \;
sudo find /var/www -type d -exec chmod 2770 {} \;

If you decide to use /www, change the /var/www in those commands to /www.

Now that you are inside either /www or /var/www and have given your user privileges, let’s clone your repository, install dependencies, and build your React app. You can either clone it with HTTPS or set up a deploy key and clone it via SSH.

git clone [Your repository URL]
cd [Your Repository Name]
sudo npm install
sudo npm run build

Install and Configure Nginx to serve your application

sudo apt-get install nginx

To configure Nginx, go /etc/nginx/sites-available/. There will be a template default file so if you would like to keep it, copy it. After you do that, use your favorite text editor(I’d recommend vim) and change /etc/nginx/sites-available/default to:

server {
   listen 80 default_server;
   root /var/www/[Your repo name]/build;
   server_name [your.domain.com] [your other domain if you want to];
   index index.html index.htm;
   location / {
   }
}

This allows Nginx to serve your React app at your domain or your IP! index.html will be called first whenever yourdomain.com/ is accessed. If you put your repository inside /www instead of /var/www, change the text after root.

If you’d like to serve other static files, such as a pdf document inside a folder like /var/www/[your repo name]/files/, you can do that by adding this inside the configuration file:

location /files/ { 
   autoindex on;
   root /var/www/[your repo name]/files;
}

So /etc/nginx/sites-available/default will look like this:

server {
   listen 80 default_server;
   root /var/www/[Your repo name]/build;
   server_name [your.domain.com] [your other domain if you want to];
   index index.html index.htm;
   location / {
   }
}
location /files/ { 
   autoindex on;
   root /var/www/[your repo name]/files;
}

For more information on configuring Nginx go here.

Now start up Nginx!

sudo service nginx start

If you changed up your repository or made any changes to the configuration, you can restart Nginx with:

sudo service nginx restart

And you’re done! If you go to your browser and type in the IP address of your server or your domain, you should see your React app live!

If you enjoyed reading it, please leave a clap/comment! I’m pretty new at this and I’d like to get better — any response is welcome :)

Also, check out my other posts!

Timothy Ko - Medium

Before the rise of Single Page Applications, applications would render a full HTML document with CSS on the server using PHP, Java or another language and use JavaScript/JQuery and AJAX requests to provide a specific set of interactions a user can have with the web page. This worked very well with Django’s templating system and static files since Django did all of the work for you, loading files that were needed for a specific URL.

But then came Single Page Applications.

Instead of reloading each page due to an action such as a button click— and making the user wait a little longer — Single Page Applications allow for fast reload speeds between pages with asynchronous HTTP requests, providing a seamless user experience, but with a sacrifice of initial load time. Many have or are in the progress of switching to using Javascript frameworks for their front-end stack, and pretty much splitting the front-end from the back-end. This essentially renders Django templates useless.

In my opinion, the best way to use Django for web applications is to use it to build a REST API and use front-end frameworks — React.js, Angular.js, Ember.js, Vue.js — to render your web page, which can be completely independent of Django.

REST APIs

Essentially, an API is the interface the server/backend provides so that apps can talk to them. A REST API is an API that follows a set of rules called REST(Representational State Transfer) and an API endpoint are certain functions of the interface.

Let’s take Instagram for an example, who published their API to the public. So say you wanted to know information about user 1234567, his/her name, how many followers they have, their bio, etc. Given an ACCESS-TOKEN that you get from Instagram, you make a request to an endpoint:

https://api.instagram.com/v1/users/12345678/?access_token=ACCESS-TOKEN

Instagram web servers will then perform certain functions that include searching through their database to get that user and will then return this text, which is in JSON format:

{
 “data”: {
     “id”: “1234567”,
     “username”: “snoopdogg”,
     “full_name”: “Snoop Dogg”,
     “profile_picture”: "http://distillery.s3.amazonaws.com/profiles/profile_1574083_75sq_1295469061.jpg",
     “bio”: “This is my bio”,
     “website”: “http://snoopdogg.com",
     “counts”: {
         “media”: 1320,
         “follows”: 420,
         “followed_by”: 3410
     }
  }
}

If you want more information such as their followers you would then have to make another request to a different URL to get a list of their followers. There are also ways to add users, add photos, etc. if you provide some data, but it is up to instagram whether they want to allow the public to do so. This is how 3rd party apps are created to track who unfollowed you. In fact, Instagram’s mobile apps call a bunch of these API functions and displays this data in a very sleek and fast way(it’s actually very fascinating in how they make their app fast, Instagram’s CTO talks about it here)

Django REST Framework

One great and common way to implement an API with Django is by using Django REST Framework, a Django package packed with powerful but flexible tools to build a REST API. It allows you serialize your data(translating your model objects to — in this case, text), quickly write views/endpoints and test them, add authentication, and much more.

With this, you will be able to separate your back-end from your front-end, enabling you to expand with other formats like IOS and Android applications without just sticking to just web apps. In addition, your front-end and back-end won’t be integrated in a very tight and complex way, which make debugging a living hell. Even companies like Instagram and Doordash have used Django to implement their API as their back-end service, with Instagram using React.js to develop their web app.

This, in my opinion, is the best way to use Django.

More Resources

• What is REST?
• Official Django REST Framework
• Django REST Framework tutorial

If you enjoyed reading it, please leave a clap/comment! I’m pretty new at this and I’d like to get better — any response is welcome :)

Also check out my other posts!

Timothy Ko - Medium

This is guide is mainly meant for freshmen and sophomores, or even high school students who want to get their first software engineering internship.

Overview

Landing your first internship is pretty hard when you don’t have any experience. You need to make yourself valuable and prove to companies that you are competent and that you are capable of contributing. Fortunately, Software Engineering is different from many fields in that you can get A LOT of experience on your own. One google search of a programming language with result in thousands of tutorials, and plus, there are plenty of great online communities that allow you to fix so many different problems you would run into.

The best way to gain this experience, in my opinion, is through learning new technologies and programming techniques by developing side projects. With various projects, you show that you are passionate about this field and that you are able to learn new technologies.

So, here are some things you should start off learning:

Basics that you need to understand at first

Honestly, you don’t need to master these right away. You will, however, encounter these technologies quite a bit while building projects so having an understanding of these will help you a lot. And as you build more projects, you will start to be more familiar with these tools/technologies. Below, I’ve stated some things you should know about each one— at the very minimum.

• Version Control — Any software team will have a version control because it allows a team or even an individual manage revisions. I recommend Git, but another popular one is Subversion. Many open source repositories are also on Github. At least know how to set up a repository, add, commit, push, and branch.
• Linux/Unix — Know Linux directory structures and important file paths. Know basic commands in shell(command line) including cd, li, pwd, cat, mv, mkdir, man, touch, grep, what root is, and an editor(ex: nano or vi),=. There is no doubt you will encounter using shell while programming, especially to programs and look at logs.
• Databases and SQL — Download MySQL or PostgreSQL, which are relational databases. Learn how to create tables with fields. Understand common database structures and relationships(foreign key, many-to-many, etc.)
• HTTP / REST APIs —what is used to transfer data through the internet. Most companies will have web based APIs that you will use to get data. Understand the basics of what they are. With Backend Web frameworks you will be able to develop an API. With the Frontend, you will be able to use these APIs to get information and display them.
• JSON — Javascript Object Notation — a very common way of transferring data from a browser to a server. Understand and know the syntax. Know how Javascript can convert this into a Javascript object.
• Java or C/C++or Python — having a deep understanding in one of these languages will allow you learn the other a lot faster but most internships will require you to know at least one of these languages. Try to implement algorithms and develop simple applications.
• Using other libraries — understand how to install different packages either manually or with package managers and be able to read through documentation and know how to use the library. Some package managers are npm for Node Js or pip for python.

Frontend Web Development

• HTML/CSS/Javascript (Jquery)— the very basics of a web page. Javascript is a very popular and has a very vibrant of ecosystem of technologies and frameworks. If you want to do Web development, you must learn it.
• Bootstrap — CSS/Javascript Library that makes it easier to build a web page.
• Frontend Javascript Web Frameworks — React & Redux / Angular / Vue.js / Ember.js — These frameworks make developing complicated web applications a lot easier than just pure HTML/CSS/JS. To learn more about which ones to learn click here.

Side-note: The “hottest” Frontend Javascript Web Frameworks often change very fast. React is the most popular at this very moment.

Backend Web Development

Learning one of these frameworks will give you a much better understanding of how web applications work. In addition, you can learn how to develop RESTful APIs with these frameworks and know how to deploy these using cloud technologies while learning about different tools like error reporting, caching & Redis, web & proxy servers, load balancing, etc.

• Django — Framework based on Python. I actually learned this first because I already knew python and I wanted to dive deeper into python so I could possibly use it for data science, machine learning, etc later.
• Node.js— Very very popular server-side Javascript. Express is one the most popular web frameworks with Node.js. And because it is Javascript and has asynchronous I/O, Node.js is very fast and is capable of executing commands in parallel, optimizing an application’s scalability. Real-time applications with Web-sockets are much easier to build with Node.js.
• Ruby on Rails — based on the language Ruby. This is a very popular framework many developers still love but Node.js has been smashing Ruby and continues to expand in the market.

Popular technology stacks for Web Development are MEAN(MongoDB, Express, Angular, Node) or LAMP(Linux, Apache, MySQL, PHP) where you can switch out PHP for some other language.

Mobile Development

• IOS / Android — should be pretty self-explanatory. These are called native apps.

If you have more time, dive deeper into programming languages and base concepts. Look into:

• NoSQL and MongoDB — a different type of database where data can be added anywhere at any time. This is best for projects where there are evolving data requirements, or when speed and scalability are imperative. Node.js is often paired with MongoDB instead of relational databases such as MySQL.
• Cloud Computing — Instead of building and setting up your own servers, you can use buy “servers” by paying for the time they are up running. Learn to use different deployment tools such as Fabric, Chef, Puppet, Docker and web technologies like Apache, Nginx, Gunicorn that allow you efficiently deploy your app. Study and know how to use tools that allow for Continuous Deployment. Popular cloud services are AWS, Heroku, Microsoft Azure, Google Cloud, DigitalOcean. Heroku is one of the easier ways to deploy your website/web app
• WebSockets—A technology that allows the client and server send each other messages when new data is available. Enables easier creation of real-time applications such as chats and games.

Conclusion

Remember that as you build up your repertoire of skills and have projects to showcase, push them to your Github account. Github is a great and tangible way to demonstrate that you actually have done projects and have passions outside of school.

There are so many projects you can work on. But also, don’t forget about open source projects that allow anyone to work on it. Search for projects that are more welcoming to beginners.

Learning these things will often differentiate you from your peers, whom most don’t even know what those technologies are. However, I’d like to emphasize that as you learn these technologies, languages, and frameworks, make it a goal to become good at learning and love it. I’d admit I don’t have much experience at software engineering but even with my limited time in this field, I’ve realized that unless you’re fine with being obsolete, you cannot stop learning as a developer. New and better technologies are always emerging — especially with javascript — and are always constantly replaced by the next trendiest and hottest one. But the thrill of the “Hello, world” that marks the beginning of a tutorial never seems to fade, you will be golden. However, if this doesn’t excite you, you might need to reconsider this field. As a software developer, you must be able to meet the demands of the dynamic and challenging tech world.

Even this summer, I worked with 5 different languages, 3 web frameworks, and many different tools. So invest in your ability to learn quickly and proficiently. And as you have a stronger foundation in programming in general, understanding key concepts and underlying technology, you will be able to pick up things a lot faster. This will take time — in fact, A LOT of time — and you will have to give up hanging out or partying on a Saturday night.

But, in the end, it will be worth it :)

Other Resources

• Every Programmer Should Know — A collection of (mostly) technical things every software developer should know.
• CodeAcademy — use this at first if you don’t have prior experience with a language. It’s a very good website for hands-on tutorials.
• StackOverflow
• Google :)

Note: I know that any programmer must understand Big-O notations, algorithms, and data structures but these are classes that any CS major will take.

Thanks for reading!

If you enjoyed reading it, please leave a clap/comment! If you’d like a more comprehensive guide on getting internships, let me know! I’d like to get into deployment and development guides with Django, Node.js, and React soon. I’m pretty new at this and I’d like to get better — any response is welcome :)

For me, learning Django was very overwhelming at first — I dove straight into the official documentation and its tutorial, making it very frustrating as I got lost every step of the way, getting bombarded with a ton of new terms and acronyms and specific guides giving me different ways to install Django. My goal with this post is to provide a very basic understanding of Django and its overall structure, hopefully easing the learning process a bit by allowing beginners to have a general idea of what’s happening before they dive into the details.

Here are the main ideas I’m going to go through in this post:

• What is a Web Framework?
• Django Architecture
• Django Apps and Core Files
• Example

What is a web framework?

Whenever you type in a URL, your browser makes a request to a server, which will send files — generally HTML — and your browser will process it and display it. At the end of the day, no matter how complicated your web application is, all it does is send files due to a request.

A web framework provides a toolkit of reusable components allowing developers to focus on building their app rapidly without reinventing the wheel. Problems like how do you map a certain URL to a set of code or how do you dynamically create a page according to some data from your database arise in every web app. A web framework will allow you to do that quickly so you can focus on writing the code for the given URL or on the contents of a certain page. These two main problems are called routing and templating, respectively, and are main components in many web frameworks.

Note: Front-end web frameworks are entirely different

Django is one of the most popular and huge open-source web frameworks. It is written in python and companies like Instagram, Doordash, and Disqus use it in their systems, which hopefully is enough to show that Django is robust and scalable.

Django Architecture

Django follows a Model-View-Controller(MVC) architecture, which is split up into three different parts:

• The Model is the logical data structure behind the entire application and is represented by a database(generally relational databases such as MySql, Postgres).
• The View is the user interface — what you see in your browser when you visit a website. These are represented by HTML/CSS/Javascript files.
• The Controller is the middleman that connects the view and model together, meaning that it is the one passing data from the model to the view.

With MVC, your application will revolve around the model—either displaying it or manipulating it.

So say a user will enter a URL in their browser, that request will go through the internet protocols, to your server, which will call Django. Django will then process the given URL path, and if it matches an URL path you have explicitly stated, it will call the Controller, which will then perform a certain action, such as get an entry from your Model(database) and then render a View(ie: JSON text, HTML/CSS/JavaScript Web page).

Django Apps and Core Files

Any Django project will have at least one Django app. Yes, I know, it’s a little confusing. A Django project encompasses the application and all its components, while a Django app is a sub-container of the application with its own functionality that, in theory, may be reusable in another application without much modification. For simplicity’s sake, we will create one app called myapp under a Django project called MySite.

A typical Django project structure will look like this:

MySite/
    manage.py
    MySite/
        __init__.py
        settings.py
        urls.py
        wsgi.py
    myapp/
        views.py
        models.py
        __init__.py
        admin.py
        tests.py
        urls.py
        static/ 
            myapp/
                style.css
                index.js
                background.jpg
        templates/
             index.html
             aboutus.html
             post.html 
        migrations/
            __init__.py
            0001_initial.py

All the files under myapp/ describe the Django app named myapp.

• myapp/models.py is the Model, or where you define your database. Take a blogging website for example. At its very minimum, you would have a table of blog posts and a table of comments. Each blog post has a title, author, date, and its contents, while comments have the same thing too.
• myapp/views.py is the Controller. Um, but why is the controller called views? Here’s a quick answer in the official documentation if you’d like to know. Inside views.py you will define different functions/classes( Django offers support for both but most people still use functions) A function defines what happens when a certain URL is accessed and an HTTP request is made the server. Common actions would be to query the database for records and render a certain HTML template file.
• Everything under myapp/templates/myapp/ are templates or HTML files that define your View. When a function in views.py renders an HTML file, it can pass objects such as a list of comments in which you can use special syntax to display those comments. Within each template, you can get static files like CSS, Javascript files, or images to give the webpage life.
• urls.py is the URL configuration file. This is the file that allows you to map a certain URL to a certain function in views.py. Let’s say you have a server receiving requests from the domain mydomain.com. If you go to mydomain.com/about-us, a certain function such as aboutus() will generate a response. Django will also allow you include important information in the URL. An example would be if you wanted to get a blog post with an id of 4. You make Django send the number "4" to a function named blogpost(blog_id) when you go tomydomain.com/blogs/4/and

Example

To give you a little bit more understanding, I have provided tiny snippets of code of different files. The bold are file names that the code below it belongs to.

#myapp/urls.py
from .myapp import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^about-us/$', views.aboutus name="about us"),
    url(r'^post/(?P<pk>[0-9]+)/$', views.post, name="post"),
]

#myapp/views.py
from django.shortcuts import get_object_or_404, render

def aboutus(request):
    return render(request, 'myapp/aboutus.html')

def post(request,pk):
    post = get_object_or_404(Post, pk=pk)
    return render(request, 'myapp/post.html', {
        'post': post,
    })

#myapp/models.py
class Post(models.Model):
    title = models.CharField(max_length=200)
    description = models.TextField()
    content = models.TextField()
    author_name = models.CharField(max_length=100)
    date_written = models.DateField(auto_now=True)

#myapp/templates/myapp/post.html
<!DOCTYPE HTML>
<html>
    <body>
        <h1>{{post.title}}</h1>
        <div>
            <p>{{post.content}}</p>
        </div>
    </body>
</html>

The class Post in models.py describes a table in the database. This is your Model. Each Post entry has a title, description, content, author_name, data_written.

• If a user goes to mydomain.com/about-us, Django will look in urls.py for /about-us — which in this case, is the first line. The function aboutus in myapp/views.py will be called, which will render aboutus.html.
• If a user goes to mydomain.com/post/4/, Django will call post in myapp/views.py but also pass 4 as the variable pk into the same function. (?P<pk>[0–9]+) is a regular expression that looks for the number — in this case, “4”. post() will then search(query) for a Post object(includes the title, description, etc.) with an id of 4 in our database and send it to template post.html and render it. If it can’t query an entry with an id 4, it will return a 404 error.

Note that there is a url.py under myapp/ and MySite/. MySite/url.py is the root URL configuration file that Django looks at first. So myapp/url.py must be linked in MySite/urls.py to be used. For example, I can make anything with mydomain.com/myapp/ in the beginning look up URLs at myapp/urls.py, where Django will try to match the rest of the URL.

Start Learning!

So yeah, I think that’s about it for this post. Everything here just barely skims the surface, but hopefully with this, you are able to understand the very basics of how Django works. Here are some tutorials I’d recommend that dive deep into Django implementation step by step:

• The Official Django Tutorial
• Django Girls Tutorial
• Modern Django Series by Dylan Stein — provides an extensive walkthrough of Django explaining every tool you use.

Thanks for reading!

If you enjoyed reading it, please leave a clap/comment! I’m pretty new at this and I’d like to get better — any response is welcome :)