The Journey of #100DaysofCode (@eliehannouch)

What does init do? How it’s running?

2 Likes

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
3 Likes

Thank you for the valuable info :green_heart:

2 Likes

100daysofcode - Day 20

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. :boom::heart_eyes::blush:

In today’s post, we will dive :diving_mask: 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. :face_with_hand_over_mouth::smiling_face_with_three_hearts::partying_face:

Let’s explore the building blocks of a template in Golang ? :jigsaw::clubs:

  • {{.}} : 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. :hugs:
  • {{if .Done}} {{else}} {{end}}: define a normal if - else statement :sweat:
  • {{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}} &#10004</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)
  }

4 Likes

100daysofcode - Day 21

Hello folks, another day is here the 21/100 of this amazing journey. :heart_eyes::boom: And some new informations are required to wrap it successfully.

For me today, was !== programming day , where I was away all the day :sun_with_face: from my macbook :computer::sob:.

Why ⁇ :thinking::thought_balloon:

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 :lebanon: including the one and only @Darine_Tleiss our women techmakers ambassador :smiling_face_with_three_hearts::fist: and one of the most active community builders :construction_worker_woman:, alongside with @abedattal :sunglasses: checking the technical setup in the conference location :round_pushpin: OMG :boom: It was a funny day.

  • Setup is tested :white_check_mark:

  • Some rehearsals are done :cinema:

  • The broadcasting connections for a smooth online experience are getting ready :sunglasses::face_with_hand_over_mouth:

And here a sneak peek of our cosy conference room from @abedattal lens :camera_flash:

 

And now our dearest community, it your turn to reserve a free spot to join us for a full technology day :smiling_face_with_three_hearts::heart_eyes:, on Saturday the 2nd of July.

  • Based in Lebanon :lebanon: → Join us on-site :house: with your laptop :computer: and be ready for some informative sessions, a lot of networking, competitions and a delicious launch break :pizza::cup_with_straw:

  • WorldWide ?? :earth_africa: → We will be more than happy :face_with_hand_over_mouth: to have you online with us on our live streaming via Google Meet :rocket:

  • 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 !!

5 Likes

100daysofcode - Day 22

Hello folks, another day is here. Let’s learn some new information and keep proceeding in this amazing journey. :boom::rocket:
In today’s post we will move from the programming part, to talk about an amazing architectural pattern. “ The Model View Controller :fist::heart_eyes:

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. :man_technologist::four_leaf_clover:

Why is the separation done ? :thinking::thought_balloon:

  • The separation of concerns, provide a better division of labor and improved maintenance. :hammer_and_wrench::innocent:

Model ? View ? Control ? :hugs:

  • Model: It manages the data and business :briefcase: logic.

  • View: Handle layout and display. :tv:

  • Controller: Routes commands to the model and view parts :racing_car:

Example

The Model :sunglasses:

  • 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 :desktop_computer:

  • 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 :video_game:

  • 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.
6 Likes

100daysofcode - Day 23

Hello folks, the 23th day is already here and some new informations are needed to wrap it up and dive into a deep sleep :joy::smiling_face_with_three_hearts:

In yesterday’s post we talked about the Model View controller Architecture, when to use it and how to do so. :fist::boom:

In today’s post we are gonna talk about a new important architecture, the MVP.

MVP stands for ? :thinking:

  • M → Model
  • V → View
  • P → Presenter

MVP == MVC ?? :boom:

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 ? :rocket:

  • 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 ? :heart_eyes:

  • 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 ? :desktop_computer:

  • 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
6 Likes

100daysofcode - Day 24

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. :boom::rocket:

In yesterday’s post we talked about the Model View Presenter :desktop_computer: architecture, where we explored it and learned how it divides our project into different layers. :smiling_face_with_three_hearts:

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” :man_technologist:

MVVM stands for ? :fist:

  • 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 :art: – from the development :boom: of the business logic or back-end logic so that the view is not dependent on any specific model platform. :sunglasses:

Components of MVVM pattern ?

  1. 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). :smiling_face_with_three_hearts:

  2. 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. :star_struck:

  3. 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. :face_with_hand_over_mouth:

4 Likes

100daysofcode - Day 25

Hello friends, the day 25 is already here. But it was an amazing unforgettable one :smiling_face_with_three_hearts::smiling_face_with_three_hearts:. 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 :partying_face: , informative sessions :heart_eyes:, inspirational talks and a delicious food break :pizza::cup_with_straw:.

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 :heart::white_heart:, that made us so proud of her inspirational story.

Thank you for our partners, speakers and organizers that made our day a special one :boom::rocket:

And now let’s share some photos from the event with our amazing community.

Stay tuned for our official Lebanon MUG post, with a lots of amazing pictures :smiling_face_with_three_hearts:

6 Likes

100daysofcode - Day 26

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. :heart_eyes::rocket:

In today’s post we will talk about JWT , The Json Web tokens, why to use them and when to do so. :thinking::boom:

What is a JWT ? :hugs:

  • 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. :sunglasses:

  • JWT’s can be used as a signed token, to verify the integrity of the claims contained within it :relaxed::innocent:, while encrypted tokens hide those claims from other parties. When tokens are signed :writing_hand: 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. :rocket:

4 Likes

100daysofcode - Day 27

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

  1. Header
  2. Payload
  3. 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.

  • Example:

    {
    
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true
    
    }
    

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.

  • Example using HMAC SHA256

    HMACSHA256(
    
    base64UrlEncode(header) + "." +
    
    base64UrlEncode(payload),
    
    secret)
    

Example
         

4 Likes

100daysofcode - Day 28

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. :rocket::boom:

In today’s post we will talk about monolithic architecture, when to use it and why to do so? :smiling_face_with_three_hearts::star_struck:

What is a monolithic architecture? :gear: :thinking:

  • A monolithic architecture is a singular, large computing network :cloud: with one code base that couples all of the business :briefcase: 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. :man_technologist::fist:

           

Advantages of monolithic architecture :white_check_mark::hugs:

  • Simplicity of development: when the application is built with one code base, the development process is easy… :heart_eyes:

  • Simplicity of testing: You test only one service without any dependencies. Everything is usually clear. :male_detective:

  • Debugging Ease: With all code located in one place, it’s easier to follow a request and find an issue. :mag_right:

  • 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. :moneybag:

Disadvantages of monolithic architecture :x: :sob:

  • 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.
4 Likes

100daysofcode - Day 29

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. :boom::rocket:
In today’s post, we will talk about the micro-services architecture, its benefits and why to use it. :smiling_face_with_three_hearts:

What are micro-services ? :thinking:

  • 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. :innocent::star_struck:

Micro-services advantages ? :hugs: :white_check_mark:

  • 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.

  • Technology flexibility: 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.

         

Micro-services disadvantages ? :x::sob:

  • 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.

4 Likes

100daysofcode - Day 30

Hello folks, today marks our 30th day in this amazing journey and some new information are required to wrap this day up. :partying_face::star_struck:

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. :innocent::smiling_face_with_three_hearts::rocket:

What is Serverless Architecture ? :thinking: 🫣

  • 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. :boom::heart:

How Serverless Works ?

     

  • 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)

  • 4- Trigger-based tasks

4 Likes

100daysofcode - Day 31

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 " :star_struck::rocket:

What is Agile? :thinking::boom:

  • 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. :grin::slightly_smiling_face:

  • 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.:innocent:

             

So what’s Agile methodology? :thinking:

  • 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.

Agile pros and cons :x::white_check_mark:

     

Agile Values :partying_face: :fist: :hugs:

  • 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.
4 Likes

100daysofcode - Day 32

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. :star_struck::partying_face:
In yesterday’s post we talked about the Agile methodology, defining why agile and what the agile manifesto is all about. :fist::smiling_face_with_three_hearts:

In today’s post, we will talk about the waterfall methodology, why it exists and why we use it.

What is the Waterfall methodology? :thinking:

  • 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. :innocent:🫡

  • 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. :handshake:

The waterfall life cycle

   

Let’s explore deeply each phase of them, starting with the requirements gathering :boom::heart_eyes:

  • 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 :white_check_mark:

  • 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 :x:

  • 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.

5 Likes

100daysofcode - Day 33

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

6 Likes

Get well soon my friend :pray:

3 Likes

Please take care! :slight_smile:

2 Likes

100daysofcode - Day 34

Hello folks, our journey counter is increasing and the 34/100 is already here. So let’s learn something new and wrap it successfully. :smiling_face_with_three_hearts::rocket:
In our last post we talked about the waterfall methodology, its winning points and when to use it. In today’s post we will dive into a new model, which is the iterative model. To learn more about its process and how it differs from other methodologies.

What is the iterative model ? :thinking:

  • The iterative process model is a software development life cycle (SDLC) approach in which the initial development work is conducted based on initial requirements that are clearly defined, and subsequent features are added to this base software product through iterations until the final system is completed.

  • The iterative model is a method for breaking down any major software development project into smaller chunks. It is specifically designed to start with the bare minimum requirements and only construct a portion of the program iteratively.

         

When to use the iterative model ? :thought_balloon:

  • When all of the system’s requirements are fully specified and understood.

  • The major requirements are stated, but as the development process progresses, some functionalities and suggested additions change.

  • While working on the project, the development team is experimenting with and learning a new technology.

Iterative model advantages :white_check_mark:

  • In an iterative paradigm, less effort is spent documenting and more time is allocated to design.

  • Early in the software development life cycle, some working functionality can be produced and released to the end users

  • End users are involved in the process, where they can swiftly provide input after each iteration, which can subsequently be incorporated into the system thereby improving the experience of the application.

  • Risks are identified and resolved during iteration.

  • Testing and debugging during smaller iterations is easy.

  • It is easily adjustable and flexible to the project’s and client’s changing requirements.


Iterative model disadvantages :x:

  • It is not suitable for smaller projects.

  • More Resources may be required.

  • Design can be changed again and again because of imperfect requirements.

  • Requirement changes can cause over budget.

  • Project completion date not confirmed because of changing requirements.

5 Likes