Hello folks, a new day and some new knowledge are required. First of all I hope that your journeys are going well. In yesterday post talked about regular expressions and their roles in Golang, how they are used to validate input, events to restrict it and much more.
In today’s post we will dive into a new amazing topic in Golang, the text templates feature that helps developers create dynamic content and show customized output to the user based on their needs.
First of all let’s explore what the Go Template package is and how we can use it to render some dynamic content based on the user and developer needs.
What is a template in Golang ?
In simple terms a template is a file that defines a specific pattern, where the developer can dynamically change the input to show different output based on the embedded rules and logic.
A template simply helps developers transform their static files into more dynamic and interactive ones.
ParseFiles in Go
Used to parse the templates to the Golang program
To parse templates in golang we used the built in function ParseFiles provided by the text/template package which creates a new Template and parses the template definitions from the named files. The returned template’s name will have the base name and parsed contents of the first file. There must be at least one file. If an error occurs, parsing stops and the returned *Template is nil .
Example
package main
import (
"log"
"os"
"text/template"
)
func main() {
template, err := template.ParseFiles("template.txt")
// Capture any error
if err != nil {
log.Fatalln(err)
}
// Print out the template to std
template.Execute(os.Stdout, nil)
}
Must & Execute Method in Golang
template.Must: Must is a helper that wraps a call to a function returning (*Template, error ) and panics if the error is non-nil.
template.Execute: Execute applies a parsed template to the specified data object, and writes the output to wr. If an error occurs executing the template or writing its output, execution stops, but partial results may already have been written to the output writer.
Example:
package main
import (
"log"
"os"
"text/template"
)
// Declare a pointer for the template.
var temp *template.Template
// we use the init() function, to make sure that the template is parsed once
func init() {
// The Must function take the ParseFiles response and perform error checking
// template.Must takes the response of template.ParseFiles and does error checking
temp = template.Must(template.ParseFiles("template.txt"))
}
func main() {
// Execute myName into the template and print to Stdout
myName := "Elie Hannouch"
err := temp.Execute(os.Stdout, myName)
if err != nil {
log.Fatalln(err)
}
}
And now let’s wrap this amazing post up, and stay tuned for tomorrow post where we will talk more about variables and loops inside the template in Golang
Hello @abedattal,
The init function is a powerful and reserved function in Golang that execute before the main() and any other function, that can be used within the package block.
Why do use it ?
Inside the init function we can setup databases connections, find the operating system type before executing, parsing a file… or any other task that we typically need to do once
Hello folks, the 20th day is here, and some interesting information is required for an amazing wrap up.
In yesterday’s post, we defined the templates in Golang, their role and how they are used to render dynamic content based on the user response, or the logic defined by the developer.
In today’s post, we will dive more into this amazing topic, exploring them more to learn how to write templates, define variables, functions, conditions and more advanced features that help us manipulate these templates in an easy and more productive way.
Let’s explore the building blocks of a template in Golang ?
{{.}} : It’s render the root element in the template √* {{.Title}} : It renders the title field in the nested element. ⫸
{{/* a comment */}} : it defines a comment in the template.
{{if .Done}} {{else}} {{end}}: define a normal if - else statement
{{range .Items}} {{.}} {{end}}: used to loop over the elements and render them through the {{.}}
Example
package main
import (
"html/template"
"log"
"os"
)
type Todo struct {
Title string
Done bool
}
type PageData struct {
PageTitle string
Todos []Todo
}
func main() {
// An HTML template
const tmpl = `
<h1>{{.PageTitle}}</h1>
<ul>
{{range .Todos}}
{{if .Done}}
<li>{{.Title}} ✔</li>
{{else}}
<li>{{.Title}}</li>
{{end}}
{{end}}
</ul>`
// Make and parse the HTML template
t, err := template.New("webpage").Parse(tmpl)
if err != nil {
log.Fatal(err)
}
// Initialize a struct storing page data and todo data
data := PageData{
PageTitle: "My TODO list",
Todos: []Todo{
{Title: "Task 1", Done: false},
{Title: "Task 2", Done: true},
{Title: "Task 3", Done: true},
},
}
// Render the data and output using standard output
t.Execute(os.Stdout, data)
}
Hello folks, another day is here the 21/100 of this amazing journey. And some new informations are required to wrap it successfully.
For me today, was !== programming day , where I was away all the day from my macbook .
Why ⁇
I was on-site, preparing for the I/O event with my amazing team in the Google developer Groups and the MongoDB User Group in Lebanon including the one and only @Darine_Tleiss our women techmakers ambassador and one of the most active community builders , alongside with @abedattal checking the technical setup in the conference location OMG It was a funny day.
Setup is tested
Some rehearsals are done
The broadcasting connections for a smooth online experience are getting ready
And here a sneak peek of our cosy conference room from @abedattal lens
And now our dearest community, it your turn to reserve a free spot to join us for a full technology day , on Saturday the 2nd of July.
Based in Lebanon → Join us on-site with your laptop and be ready for some informative sessions, a lot of networking, competitions and a delicious launch break
WorldWide ?? → We will be more than happy to have you online with us on our live streaming via Google Meet
Please check the Conference details here and don’t hesitate to reach me out for any questions. I’t will be a pleasure for me to answer any question !!
Hello folks, another day is here. Let’s learn some new information and keep proceeding in this amazing journey. In today’s post we will move from the programming part, to talk about an amazing architectural pattern. “ The Model View Controller “
What is the Model View Controller (MVC) ?
MVC is a pattern in software design commonly used to implement user interfaces, data, and controlling logic. It emphasizes a separation between the software’s business logic and display.
Why is the separation done ?
The separation of concerns, provide a better division of labor and improved maintenance.
Model ? View ? Control ?
Model: It manages the data and business logic.
View: Handle layout and display.
Controller: Routes commands to the model and view parts
The model defines what the app should contain, if the state of this data changes, then the model will usually notify the view ( to change the display as needed) and the controller ( if different logic is needed to control the view).
For example: the model in the shopping list specifies what data the item contains (itemName, price, quantity).
The view
The view defines the app’s data should be displayed.
For example: the view in the shopping list app defines how the list is presented to the user and receives the data from the model to be displayed.
The controller
The controller contains the logic to update the model or access the response from the user’s input.
For example: Shopping list, could have input forms and buttons that allow us to add or delete items. These actions require the model to be updated, so the input is sent to the controller, which then manipulates the model as appropriate, which then sends updated data to the view.
They are so similar, but the C in MVC is replaced with the presenter in the MVP, where in reality they don’t perform the same function. The Presenter can address all the UI events on behalf of the view. It takes the input from the users, proceeds the data in the Model, and then transforms the results back to the View.
Model ?
Used to work with data. A model can be an interface that is responsible for accessing APIs and local databases or cache so the main role of the model is managing data.
View ?
Implements data display. It only should be responsible for displaying things and should not contain any business logic. So the view only manages and displays the pages.
Presenter ?
known as the middle-man messenger because it implements the interaction between the model and the view. Where the model and the view cannot communicate directly so the presenter bridge the gap between them
Hello folks, the 24th day of this amazing journey is already here, a lot of new information is learned so let’s wrap this funny day with some amazing content.
In yesterday’s post we talked about the Model View Presenter architecture, where we explored it and learned how it divides our project into different layers.
In today’s post, we will discuss another architecture that extends our knowledge, and help us architecting our future softwares in a professional way. The “ MVVM architecture”
MVVM stands for ?
The MVVM stands for, Model view view model architecture.
Why MVVM ?
Model–view–viewmodel is a software architectural pattern that facilitates the separation of the development of the graphical user interface – be it via a markup language or GUI code – from the development of the business logic or back-end logic so that the view is not dependent on any specific model platform.
Model: refers either to a domain model, which represents real state content (an object-oriented approach), or to the data access layer, which represents content (a data-centric approach).
View: refer to the structure, layout, and appearance of what a user sees on the screen. It displays a representation of the model and receives the user’s interaction with the view (mouse clicks, keyboard input, screen tap gestures, etc.), and it forwards the handling of these to the view model via the data binding (properties, event callbacks, etc.) that is defined to link the view and view model.
View model: The view model is an abstraction of the view exposing public properties and commands. Instead of the controller of the MVC pattern, or the presenter of the MVP pattern, MVVM has a binder, which automates communication between the view and its bound properties in the view model. The view model has been described as a state of the data in the model.
Hello friends, the day 25 is already here. But it was an amazing unforgettable one . Today we wrapped up our big on-site conference successfully. The IO extended collaboration that happened between MUG Lebanon and the Google Developer Groups. With a lot of fun , informative sessions , inspirational talks and a delicious food break .
It was a honor for me, joining this event, representing MongoDB User Group in Lebanon, with a dedicated session of 45 min to learn more on how to deploy MongoDB on GCP. With other special speakers @Darine_Tleiss, that made us so proud of her inspirational story.
Thank you for our partners, speakers and organizers that made our day a special one
And now let’s share some photos from the event with our amazing community.
Hello family, the 26/100, a milestone is wrapped and now it’s time to share some new information and learn more to expand our knowledge.
In today’s post we will talk about JWT , The Json Web tokens, why to use them and when to do so.
What is a JWT ?
JSON Web Token is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
JWT’s can be used as a signed token, to verify the integrity of the claims contained within it , while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
When should you use JSON Web Tokens?
Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.
Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn’t been tampered with.
It was a gentle intro to a very important topic in the new web world, the JWT’s and now let’s wrap it up and stay tuned for tomorrow’s post where we will dive more into the JWT’s world.
Hello family, the 27th day is here. Let’s wrap it up successfully, by learning some new information. In yesterday’s post we introduced the JSON Web tokens, how we can use them and why to do so ?
In today’s post, we will dive more into the JWT’s, exploring their structure in deep details.
JSON Web tokens consist of 3 parts separated by dots (.)
xxxxx.yyyyy.zzzzz
Header
Payload
Signature
1- Header: The part that consists of two parts, the type of the token and which signing algorithm is being used, like RSA, SHA256.
Example:
{
"alg": "HS256",
"typ": "JWT"
}
2- Payload: The second part of the token which contains the claims.
So what is a claim? It’s a statement about an entity ( the user in most of the cases).
Types of claims
Registered claim: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.
Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.
3- Signature: To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.
Hello friends, a new day is already here, and some new information are a must. In yesterday’s post, we dived into JWT, exploring their structure and how to use them.
In today’s post we will talk about monolithic architecture, when to use it and why to do so?
What is a monolithic architecture?
A monolithic architecture is a singular, large computing network with one code base that couples all of the business concerns together. To make a change to this sort of application requires updating the entire stack by accessing the code base and building and deploying an updated version of the service-side interface. This makes updates restrictive and time-consuming.
Simplicity of development: when the application is built with one code base, the development process is easy…
Simplicity of testing: You test only one service without any dependencies. Everything is usually clear.
Debugging Ease: With all code located in one place, it’s easier to follow a request and find an issue.
Low cost in the early stages of the application: All source code is located in one place, packaged in a single deployment unit, and deployed.
Disadvantages of monolithic architecture
Reliability: If there’s an error in any module, it could affect the entire application’s availability.
Deployment: A small change to a monolithic application requires the redeployment of the entire monolith.
Scalability: You can’t scale individual components.
Barrier to technology adoption: Any changes in the framework or language affects the entire application, making changes often expensive and time-consuming.
Slower development speed: A large, monolithic application makes development more complex and slower.
Hello folks, the 29th day is already here and a new topic is needed to wrap this day successfully. In yesterday’s post, we talked about monolithic architecture, when and why to use it.
In today’s post, we will talk about the micro-services architecture, its benefits and why to use it.
What are micro-services ?
An architecture that relies on a series of independently deployable services. Each of these services have their own business logic and database. When performing any update, test, or deployment any service, this operation doesn’t affect any other service. To serve a single user request, a micro-services based application can call on many internal micro-services to compose its response.
Micro-services advantages ?
Flexible Scaling: If a micro-service reaches its load capacity, new instances of that service can rapidly be deployed to the accompanying cluster to help relieve pressure.
Agility: Promote agile ways of working with small teams that deploy frequently.
Technologyflexibility: Micro-service architectures allow teams the freedom to select the tools they desire.
High reliability: You can deploy changes for a specific service, without the threat of bringing down the entire application.
Independently deployable: Since micro-services are individual units they allow for fast and easy independent deployment of individual features.
Exponential infrastructure costs: Each new micro-service can have its own cost for test suite, deployment playbooks, hosting infrastructure, monitoring tools, and more.
Lack of clear ownership: As more services are introduced, so are the number of teams running those services. Over time it becomes difficult to know the available services a team can leverage and who to contact for support.
Development sprawl: Micro-services add more complexity compared to a monolith architecture, since there are more services in more places created by multiple teams. If development sprawl isn’t properly managed, it results in slower development speed and poor operational performance.
Added organizational overhead: Teams need to add another level of communication and collaboration to coordinate updates and interfaces.
Hello folks, today marks our 30th day in this amazing journey and some new information are required to wrap this day up.
In yesterday’s post, we talked about micro-services architecture, its benefits and why to use it. In today’s post we will talk about serverless architecture. A trending topic in the cloud based solutions and a must for any modern developer.
What is Serverless Architecture ?
Serverless architecture is a software design approach that allows developers to build and run services without having to manage the underlying infrastructure. Developers can write and deploy code, while a cloud provider provisions servers to run their applications, databases, and storage systems at any scale.
A popular serverless architecture is Function as a Service, where a developer writes the application code as a set of discrete functions.
Each function performs a specific task triggered by an event, such as incoming email, or a normal HTTP request.
These functions got deployed to a cloud provider after writing and testing them. And one any function gets triggered the cloud provider runs the targeted function on a running server or starts a new server if there is no one.
The entire deployment and running process is abstracted where the developer only focuses on writing the function logic.
Serverless Architecture Use Cases
𝟏 - Building RESTful APIs
𝟐 - Security checks
3- Continuous Integration (CI) and Continuous Delivery (CD)
Hello folks, a new day is here. The 31th from our amazing 100daysofcode. In yesterday’s post we discussed the serverless architecture, why to use it and when to do so. In today’s post we will explore a very important topic. That any tech enthusiast hears about it. “ The Agile "
What is Agile?
Agile is an approach to project management that centers around incremental and iterative steps to completing projects. The incremental parts of a project are carried out in short-term development cycles. The approach prioritizes quick delivery, adapting to change, and collaboration rather than top-down management and following a set plan.
In Agile processes, there is constant feedback, allowing for team members to adjust to challenges as they arise, and stakeholders an opportunity to communicate consistently. Though originally created for software development, the Agile approach is now widely used in executing many different types of projects and in running organizations.
Agile is technically not a methodology by itself, but rather a mindset for approaching how projects get done. It’s not considered a methodology because Agile doesn’t specify which tools and processes should be used.
Agile is, however, the umbrella term for many types of management methodologies. Scrum, Kanban, and Extreme Programming (XP) are each considered different Agile methodologies.
Individuals and interactions over processes and tools: While tools and processes are important, the Agile Manifesto prioritizes the people behind them. Having the right people in place and empowering them to interact smoothly with each other can lead to successes that tools by themselves won’t be able to.
Working software over comprehensive documentation: The creators of Agile believed that it was more important to get stuff done than get bogged down in the planning and documentation stages.
Customer collaboration over contract negotiation: Instead of siloing stakeholders off from the project, Agile aims to maintain contact with them throughout the creation process.
Responding to change over following a plan: Following a plan that doesn’t make sense to follow anymore can be counterproductive. Adaptation is central to the Agile philosophy.
Hello folks, the 32/100 day is already here, let’s dive into a new topic and extend our knowledge in the amazing world of tech. In yesterday’s post we talked about the Agile methodology, defining why agile and what the agile manifesto is all about.
In today’s post, we will talk about the waterfall methodology, why it exists and why we use it.
What is the Waterfall methodology?
The Waterfall methodology is a sequential development process that flows like a waterfall through all phases of a project (analysis, design, development, and testing), with each phase completely wrapping up before the next phase begins.
It follows the adage “measure twice, cut once.” and the success of this methodology depends on the amount and quality of the work done on the front end, documenting everything in advance, including the user interface, user stories, and all the features’ variations and outcomes. With the majority of the research done upfront, estimates of the time needed for each requirement are more accurate, and this can provide a more predictable release date.
Let’s explore deeply each phase of them, starting with the requirements gathering
Requirements: The key aspect of the waterfall methodology is that all customer requirements are gathered at the beginning of the project, allowing every other phase to be planned without further customer correspondence until the product is complete.
Design: The design phase of the waterfall process is best broken up into two sub-phases: logical design and physical design. The logical design sub-phase is when possible solutions are brainstormed and theorized. The physical design sub-phase is when those theoretical ideas and schemas are made into concrete specifications.
Implementation: The Implementation phase is when all of the actual code is written This phase belongs to the programmers in the Waterfall method, as they take the project requirements and specifications, and code the applications.
Verification or testing: Before a product can be released to customers, testing needs to be done to ensure the product has no errors and all of the requirements have been completed, ensuring a good user experience with the software. The testing team will turn to the design documents, personas, and user case scenarios supplied by the product manager to create their test cases.
Maintenance: the customer is using the developed application. As problems are found due to improper requirements determination or other mistakes in the design process, or due to changes in the users’ requirements, changes are made to the system during this phase.
Advantages of Waterfall Model
Design errors are captured before any software is written, saving time during the implementation phase.
Excellent technical documentation is part of the deliverables and it is easier for new programmers to get up to speed during the maintenance phase.
The approach is very structured and it is easier to measure progress by reference to clearly defined milestones.
Testing is easier as it can be done by reference to the scenarios defined in the functional specification
Disadvantages of Waterfall Model
Clients will often find it difficult to state their requirements at the abstract level of a functional specification and will only fully appreciate what is needed when the application is delivered. It then becomes very difficult (and expensive) to re-engineer the application.
The model does not cater for the possibility of requirements changing during the development cycle.
A project can often take substantially longer to deliver than when developed with an iterative methodology such as the agile development method.
Hello friends, today I’m writing this small message, not to mention anything new in tech or in my learning journey. For me 2-3 days ago I got infected with covid and its my 2nd time from the beginning of the pandemic.
Today, I wasn’t able to learn anything new. Just resting, taking some medicines and a hot soup.
I ask you all to take care of yourselves and your families because the disease is not easy and Covid is not a joke. Let’s protect ourselves to overcome these difficult days and not lose anything from our progress.
I ask God to protect you all, and see you tomorrow after taking a rest so that we can continue this beautiful journey together
into a new amazing 
topic in Golang, the text templates feature that helps developers create dynamic content and show customized output to the user based on their needs. 
and the returned *Template is nil 
.
is non-nil.
from my macbook 
including the one and only 
, alongside with 
OMG 
with your laptop 
→ We will be more than happy 
logic.
– from the development 
, that made us so proud of her inspirational story.
using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
with one code base that couples all of the business 
