Forem: Wassim Ben Jdida

How to upload files in Golang ?

Wassim Ben Jdida — Fri, 02 Jun 2023 11:08:00 +0000

In this blog I will be using the native Golang http package to upload files, no third party packages. We will see how to upload single and multiple files.

The HTML form

The form is simple and straight forward. The only thing to note is the enctype="multipart/form-data" attribute. This is required for uploading files.

<form action="/upload" method="POST" enctype="multipart/form-data">
  <input name="name" type="text" placeholder="name" />
  <input name="ok" type="checkbox" placeholder="ok" value="aaaaa" /> aaaaa
  <input name="ok" type="checkbox" placeholder="ok" value="bbbbbb" /> bbbbbb
  <input type="file" name="file" id="file" />
  <button type="submit">SUBMIT!</button>
</form>

Single file upload

func uploadSingleFile(w http.ResponseWriter, r *http.Request){
  file, header, _ := r.FormFile("file")
  defer file.Close()

  // create a destination file
  dst, _ := os.Create(filepath.Join("./", header.Filename))
  defer dst.Close()

  // upload the file to destination path
  nb_bytes, _ := io.Copy(dst, file)

  fmt.Println("File uploaded successfully")
}

💡Note: All of the _ underscore variables are errors, I just ignored them for the sake of simplicity. so don't do that in production.

As you noticed we get the uploaded file with the r.FormFile("input_name_here") function, it returns 3 variables, file which is the uploaded file itself, header which contains information about the file like the name, size, MIME type etc..., you can use these information to validate the file before uploading it, and finally _ which is the error if any.

Multiple files upload

First of all before you can select multiple files, you need to add the multiple attribute to the file input

func uploadMultipleFiles(w http.ResponseWriter, r *http.Request){
  // key = "file" in the form
  for key, files := range r.MultipartForm.File {
    for _, file := range files {
      dst, _ := os.Create(filepath.Join("./", file.Filename))
      f, _ := file.Open()
      io.Copy(dst, f)
    }
  }
}

Just FYI, the r.MultipartForm.File is a map[string][]*multipart.FileHeader where the key is the name of the input in the form. The file variable contains the same information as the header variable in the single file upload example, (size, name, MIME type etc...)

The other fields

To get the other fields, there are two options, which at some point you will need to use both of them.

// OPTION 1: returns a string which is the first value of the key
r.FormValue("name") // string

// OPTION 2: returns a slice of strings of all the values of the key
r.MultipartForm.Value["name"] // map[string][]string

You can use the first option when you want to get a single value, and the second option when you want to get multiple values, in our case the checkbox can have multiple values.

So r.FormValue("name") is like doing r.MultipartForm.Value["name"][0].

That's it, I hope you enjoyed this tutorial. this blog is originally posted on my blog

The pragmatic programmer book tips (Part 4)

Wassim Ben Jdida — Sun, 14 Nov 2021 07:11:57 +0000

#30 - You Can't Write Perfect Software

But Pragmatic Programmers take this a step further. They don't trust themselves, either. Knowing that no one writes perfect code, including themselves, Pragmatic Programmers code in defenses against their own mistakes.

#31 - Design with Contracts

In languages that do not support DBC (Design By Contracts) in the code, this might be as far as you can go—and that's not too bad. DBC is, after all, a design technique. Even without automatic checking, you can put the contract in the code as comments and still get a very real benefit. If nothing else, the commented contracts give you a place to start looking when trouble strikes.

#32 - Crash Early

One of the benefits of detecting problems as soon as you can is that you can crash earlier. And many times, crashing your program is the best thing you can do. The alternative may be to continue, writing corrupted data to some vital database or commanding the washing machine into its twentieth consecutive spin cycle.

#33 - If It Can't Happen, Use Assertions to Ensure That It Won't

"This code won't be used 30 years from now, so two-digit dates are fine." "This application will never be used abroad, so why internationalize it?" "count can't be negative." "This printf can't fail."
Let's not practice this kind of self-deception, particularly when coding.
Whenever you find yourself thinking "but of course that could never happen," add code to check it.

#34 - Use Exceptions for Exceptional Problems

One of the problems with exceptions is knowing when to use them. We believe that exceptions should rarely be used as part of a program's normal flow; exceptions should be reserved for unexpected events. Assume that an uncaught exception will terminate your program and ask yourself, "Will this code still run if I remove all the exception handlers?" If the answer is "no," then maybe exceptions are being used in nonexceptional circumstances.

#35 - Finish What You Start

We all manage resources whenever we code: memory, transactions, threads, files, timers—all kinds of things with limited availability. Most of the time, resource usage follows a predictable pattern: you allocate the resource, use it, and then deallocate it. However, many developers have no consistent plan for dealing with resource allocation and deallocation.

#36 - Minimize Coupling Between Modules

You can see symptoms of this phenomenon in a number of ways:
1. Large C or C++ projects where the command to link a unit test is longer than the test program itself

2. "Simple" changes to one module that propagate through unrelated modules in the system

3. Developers who are afraid to change code because they aren't sure what might be affected

The Law of Demeter for functions attempts to minimize coupling between modules in any given program. It tries to prevent you from reaching into an object to gain access to a third object's methods.

#37 - Configure, Don't Integrate

First, we want to make our systems highly configurable. Not just things such as screen colors and prompt text, but deeply ingrained items such as the choice of algorithms, database products, middleware technology, and user-interface style.
These items should be implemented as configuration options, not through integration or engineering.

#38 - Put Abstractions in Code Details in Metadata

Use metadata to describe configuration options for an application: tuning parameters, user preferences, the installation directory, and so on.
Metadata is any data that describes the application—how it should run, what resources it should use, and so on. Typically, metadata is accessed and used at runtime, not at compile time. You use metadata all the time—at least your programs do. Suppose you click on an option to hide the toolbar on your Web browser. The browser will store that preference, as metadata, in some sort of internal database.

#39 - Analyze Workflow to Improve Concurrency

In many projects, we need to model and analyze the user's workflows as part of requirements analysis. We'd like to find out what can happen at the same time, and what must happen in a strict order. One way to do this is to capture their description of workflow using a notation such as the UML activity diagram

The pragmatic programmer book tips (Part 3)

Wassim Ben Jdida — Tue, 09 Nov 2021 20:49:40 +0000

#20 - Keep Knowledge in Plain Text

Plain text is made up of printable characters in a form that can be read and understood directly by people,
e.g: Fieldl9=467abe is meaningless, DrawingType=UMLActivityDrawing is better.

#21 - Use the Power of Command Shells

Every woodworker needs a good, solid, reliable workbench, somewhere to hold work pieces at a convenient height while he or she works them. The workbench becomes the center of the wood shop, the craftsman returning to it time and time again as a piece takes shape. For a programmer manipulating files of text, that workbench is the command shell.

#22 - Use a Single Editor Well

We think it is better to know one editor very well, and use it for all editing tasks: code, documentation, memos, system administration, and so on

#23 - Always Use Source Code Control

#24 - Fix the Problem, Not the Blame

Embrace the fact that debugging is just problem solving, and attack it as such. It doesn't really matter whether the bug is your fault or someone else's. It is still your problem.

#25 - Don't Panic

If your first reaction on witnessing a bug or seeing a bug report is "that's impossible," you are plainly wrong. Don't waste a single neuron on the train of thought that begins "but that can't happen" because quite clearly it can, and has.

#26 - "select" Isn't Broken

We worked on a project where a senior engineer was convinced that the select system call was broken on Solaris. No amount of persuasion or logic could change his mind (the fact that every other networking application on the box worked fine was irrelevant). He spent weeks writing work-arounds, which, for some odd reason, didn't seem to fix the problem.
When finally forced to sit down and read the documentation on select, he discovered the problem and corrected it in a matter of minutes. We now use the phrase "select is broken" as a gentle reminder whenever one of us starts blaming the system for a fault that is likely to be our own.

#27 - Don't Assume It—Prove It

Don't gloss over a routine or piece of code involved in the bug
because you "know" it works. Prove it. Prove it in this context, with this data, with these boundary conditions.

When you come across a surprise bug, beyond merely fixing it, you need to determine why this failure wasn't caught earlier. Consider whether you need to amend the unit or other tests so that they would have caught it.

#28 - Learn a Text Manipulation Language

There is a growing number of good text manipulation languages. Unix developers often like to use the power of their command shells, augmented with tools such as awk and sed. People who prefer a more structured tool like the object-oriented nature of Python. Some people use Tcl as their tool of choice. We happen to prefer Perl for hacking out short scripts.

#29 - Write Code That Writes Code

In the same way a woodworker invests the time in a jig, a programmer can build a code generator. Once built, it can be used throughout the life of the project at virtually no cost.

There are two main types of code generators: Passive code generators are run once to produce a result, Active code generators are used each time their results are required

The pragmatic programmer book tips (Part 2)

Wassim Ben Jdida — Mon, 27 Sep 2021 13:54:47 +0000

#10 - It's Both What You Say and the Way You Say It

It's not just what you've got, but also how you package it. Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication.

#11 - DRY—Don't Repeat Yourself

Every piece of knowledge (code, docs, ...) must have a single, unambiguous, authoritative representation within a system.

#12 - Make It Easy to Reuse

if you fail to reuse, you risk duplicating knowledge.

#13 - Eliminate Effects Between Unrelated Things

In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface.

#14 - There Are No Final Decisions

#15 - Use Tracer Bullets to Find the Target

when you're building something that hasn't been built before. Like the gunners, you're trying to hit a target in the dark. Because your users have never seen a system like this before, their requirements may be vague. Because you may be using algorithms, techniques, languages, or libraries you aren't familiar with, you face a large number of unknowns. And because projects take time to complete, you can pretty much guarantee the environment you're working in will change before you're done..
we're looking for something that gets us from a requirement
to some aspect of the final system quickly, visibly, and repeatably.
It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you're on target, adding functionality is easy.

#16 - Prototype to Learn

Prototypes are designed to answer just a few questions, so they are much cheaper and faster to develop than applications that go into production. You can prototype Architecture, New functionality in an existing system, Structure or contents of external data, Third-party tools or components, Performance issues, User interface design.

#17 - Program Close to the Problem domain

By coding at a higher level of abstraction, you are free to concentrate on solving domain problems, and can ignore petty implementation details.
you can invent a mini-language tailored to the application domain that expresses exactly what users want:

// this is my example:
if userA.balance >= transferAmount {
 tx.transfer(balance, toUserB)
} else {
 print "Fill your balance"
}

This language need not be executable. Initially, it could be simply a way of capturing the user's requirements, a specification..

#18 - Estimate to Avoid Surprises

Quick! How long will it take to send War and Peace over a 56k modem line? How much disk space will you need for a million names and addresses? How long does a 1,000-byte block take to pass through a router? How many months will it take to deliver your project

#19 - Iterate the Schedule with the Code

So you complete the coding and testing of the initial functionality and mark this as the end of the first increment. Based on that experience, you can refine your initial guess on the
number of iterations and what can be included in each. The refinement gets better and better each time, and confidence in the schedule grows along with it

The pragmatic programmer book tips (Part 1)

Wassim Ben Jdida — Wed, 22 Sep 2021 14:30:22 +0000

3 weeks ago I bought The pragmatic programmer book, I saw it on a blog and the writer really recommended it, so I said why not.

the book is full of great tips, actually each section the book talks about, ends with a tip its like a summary of the section.

the book has about 70 tip, this is part 1. I will list them and explain some of the ones that are not clear, the explanation is from the book itself.

#1 - Care About Your Craft

There is no point in developing software unless you care about doing it well.

#2 - Think! About Your Work

think about what you're doing while you're doing it. Never run on auto-pilot. Constantly be thinking, critiquing your work in real time.

#3 - Provide Options, Don't Make Lame Excuses

don't have a backup, it's your fault. Telling your boss "the cat ate my source code" just won't cut it.

#4 - Don't Live with Broken Windows

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead.

#5 - Be a Catalyst for Change

You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes you know it's right. But ask permission to tackle the whole thing and you'll be met with delays and blank stares. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.
"It's easier to ask forgiveness than it is to get permission."

#6 - Remember the Big Picture

Keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.

#7 - Make Quality a Requirements Issue

#8 - Invest Regularly in Your Knowledge Portfolio

Learn at least one new language every year. Read a technical book each quarter. Read nontechnical books, too. Look for interesting courses. Participate in local user groups, Isolation can be deadly to your career. Experiment with different environments. Stay current. Surf the Web for papers, commercial sites, and any other sources of information you can find.

It's important to continue investing. Once you feel comfortable with some new language or bit of technology, move on. Learn another one

#9 - Critically Analyze What You Read and Hear

Just because a bookstore features a book prominently doesn't mean it's a good book, or even popular; they may have been paid to place it there

Part 2 will be ready soon

Get better at reading open source code

Wassim Ben Jdida — Sun, 25 Jul 2021 17:18:05 +0000

This guide is from a personal experience and for me it was so practical, so if you have any other techniques please list them in the comment.

First let me list the main techniques i use to be able to read an open-source project. then i will explain.

1- Techniques

1- Understand what the project do
2- Understand folder names (yep this is the most important one)
3- Your skills in the project's tech stack

Understand what the project do

The first step is understanding what the project is about, why using it, what it's functionalities and what language it uses so you can read the code. this is easy for almost everybody. if you don't know what's the project is about you can't do anything.

for example you want to contribute to kubernetes for someone who is reading now doesn't even know or didn't use kubernetes before and doesn't know how kubernetes is built, won't be able to do anything.

Understand folder names

after understanding what the project is about, you need to understand the project's folder name, this is really so important.
i will give you some folder names and tell you what it may contain.

Folder	Description
build,dist	Compiled files
src,lib,	main source code
test,spec	automated tests
tools,utils,helpers	Tools and utilities
static,public	static files
...	...

golang folder names and meaning

there is a plenty of names sometimes names are meaningful and sometimes it doesn't make sense so just search for name meaning or just ask the developer, and sometimes the developer explains the folder names to make it easy for new contributors.

Your skills in the project's tech stack

last thing is your skills in the project's tech stack, for example you are experienced in ruby and react, but the project is using ruby and vue, you still can contribute but the other porject is using PHP and angular you won't be able to read the code.

after reading this, try to find an open-source project or some project that you are interested in and try to read it using these techniques.

Good luck !

Too quick, What hoisting really is ?

Wassim Ben Jdida — Thu, 04 Feb 2021 12:48:51 +0000

Simply, Hoisting in javascript is a memory space that the javascript engine sets up before executing your code.

it sets up a memory space for your variables and functions, that's what explain when you call your function and then actually create it, works.

code example:

add(2, 2) // this will work fine and it will return 4

function add(a, b){
  return a + b;
}

console.log(x); // this will return "undefined" 

var x;

if you rewrite this code in languages like python, php or go, it will throw an error, because the function is called before its defined and the variable too.

but as I said before, the javascript engine creates a memory space for your functions and variables too and it sets the value of the variables as "undefined".

so when the javascript engine start to execute your code it sees the add() function, and it recognize it cause its already in its memory, so it execute it without any issues, and for the variable too, it sees the x variable and it recognize it, but the value is set to "undefined" by default so it returns it.

some articles say that the javascript engine moves the variables and functions to top, thats not it, javascript engine doesn't do that, it just remember them cause they are already in its memory.

Understanding the fancy words in software industry.

Wassim Ben Jdida — Thu, 07 Jan 2021 11:22:04 +0000

Two days ago I was searching to understand some "fancy words" in the software industry, but it took me some time to find it and actually understand it.

so I created stupid fancy words GitHub repo to explain the words I daily find in simple and understandable way. and planning to add examples.

I'm sharing this so you guys help me out in adding more and more words and also to people who find some "magic" words while they are learning something new. cause understanding them will help you so much in mastering that topic (language or whatever cool thing you are learning).

Thanks for reading. 😄

Understanding goroutines and concurrency in Golang

Wassim Ben Jdida — Fri, 01 Jan 2021 13:43:05 +0000

this article assume that you have read about Golang, and know the basics at least.

So let me start with the definition of concurrency,
it's simply the execution of some code instructions at the same time. that's it.

Goroutines

A goroutine is a lightweight thread of execution.

A Thread, or thread of execution, is a software term for the basic ordered sequence of instructions that can be passed through or processed by a single CPU core. - stackoverflow.

so goroutine let us execute functions concurrently, how is that ?
a simple example:

package main

import (
    "fmt"
    "time"
)

func createUser(name string) {
  fmt.Println(name + " has been created successfully")
}
func uploadUserImage() {
  fmt.Println("User image has been successfully uploaded to the cloud !!")
}

func main() {
  go createUser("wassim")
  go uploadUserImage()

  time.Sleep(time.Second)
}

Output

User image has been successfully uploaded to the cloud !!
wassim has been created successfully

so as you can see the output of this simple program is not as the function order, cause they are executed concurrently so the result can be unordered.

but wait a minute, why i put that time sleep at the end there ? is it necessary why is it necessary ?

so Go program is gonna finish executing when the main function ends, So, Our two function calls are running asynchronously in separate goroutines now. Wait for them to finish, but main function doesn't wait it doesn't know that the two functions are still running, so if we remove that sleep it won't print anything to the console. try it if you want.

now lets go to channels.

Channels

Channels are the pipes that connect concurrent goroutines. You can send values into channels from one goroutine and receive those values into another goroutine.

lets start with code directly, here is an example using channels.

package main

import (
    "fmt"
)

func createUser(name string, done chan<- bool) {
    fmt.Println(name + " has been created successfully")
    done <- true
}
func uploadUserImage(done chan<- bool) {
    fmt.Println("User image has been successfully uploaded to the cloud !!")
    done <- true
}

func main() {

    done := make(chan bool)

    go uploadUserImage(done)
    fmt.Println("Image uploaded: ", <-done)

    go createUser("wassim", done)
    fmt.Println("User created: ", <-done)
}

So let me first tell you what is the difference between this chan<- , this <-chan and this chan.

"chan" => in the function parameter, means that we will read and write from that channel, its a data type.
"chan<-" => means that we will write only
"<-chan" => means that we will read only

the output of this progam:

User image has been successfully uploaded to the cloud !!
Image uploaded:  true
wassim has been created successfully
User created:  true

so in the main function we created a channel named done, we passed that channel as a parameter to our workers (createUser, and upload), and whenver a worker is done we notify the main function.
we put in the channel with channelName <- VALUE

and we consume the message from a channel like this <-channelName

if we don't consume the message, the goroutine function is not gonna print anything cause main will not wait for it, so by using <-done we are telling the main function to wait until we get a message from the worker.
so if we removed this line here

fmt.Println("User created: ", <-done)

we will get an output like this:

User image has been successfully uploaded to the cloud !!
Image uploaded:  true

so <-done is simply blocking the main function from exiting. and therefore ending the program from executing.

And this is what is called Channel Synchronization, its just a fancy word that means blocking until a goroutine finish executing.

But, When waiting for multiple goroutines to finish, you may prefer to use a WaitGroup.

WaitGroup

To wait for multiple goroutines to finish, we can use a wait group.

Again, lets jump directly to code, and then i will explain how and why.

package main

import (
    "fmt"
    "sync"
    "time"
)

var wg sync.WaitGroup

func createUser(name string) {
    defer wg.Done()
    fmt.Println(name + " has been created successfully")
}

func uploadUserImage() {
    defer wg.Done()             // defer -> it will delay the execution of this func we upload the user image
    time.Sleep(time.Second * 3) // just to say that this is an expensive function (that took 3s)
    fmt.Println("User image has been successfully uploaded to the cloud !!")
}

func main() {

    go createUser("wassim")
    go uploadUserImage()

    wg.Add(2)
    wg.Wait()
}

well, to use WaitGroup, we need to import the sync package, then we declared a global variable wg.

now let me explain how the WaitGroup works. the wg.Add(NUMBER_OF_GOROUTINES) this function increment the number of the running goroutines, the wg.Done() will decrease the number of goroutines, so whenever a worker (function) is done working you fire the wg.Done() function the defer keyword just tells the function to delay until the main function ends its work (by main function i mean its parent wich is the upload and create function), lastly the wg.Wait() this function blocks the program from exiting until the number of goroutines is 0. so wg.Done() will decrease until we reach the 0 then the wg.Wait() will fire, and the program exit/finish.

Thanks for reading, this is my first post, so if there is anything !good let me know :)

More to learn about GO