Accordions are one of the most commonly used UI components for any website. For example FAQs section of the website, where only the question is shown, and when clicked the answer just opens up. Generally, we handle this by creating 2 divs and adding some javascript to handle the open and close of the accordion. But recently I stumbled upon this hidden gem in HTML that eliminates the need of all this - <details>

We can simply design a simple FAQ or summary section with <details> HTML tag without using Javascript!!! 🤯🤯🤯. And the best part... it is supported by all the modern browsers (obviously except IE :( ) - browser compatibility.

Using <details> tag

There are two elements here: <details> and <summary>. <details> is the wrapper for all the content you want to show and hide, and contains the - well, the summary and title of the section. <summary> is optional, if you do not add it, the browser will use some default text. For example, in Firefox and Chrome, it is Details. Below is a sample HTML markup:

<details>

<summary>Details</summary>

<p>Something small enough to escape casual notice.</p>

</details>

And it will render like:

This markup can be designed with CSS as any other HTML element. Now for creating beautiful accordions all you need is just HTML and CSS (and a will to let go of IE).

Demo: https://itsopensource.com/demos/details/

Cheers.

Originally published at https://itsopensource.com.

Creating accordions with native HTML was originally published in itsopensource on Medium, where people are continuing the conversation by highlighting and responding to this story.

The simple and easiest way to do this is:

git log — online — all

Consider this example:

Here if we check out to commit id 95613ab Fix more TOC links and then see the git history with git log or git log — oneline you will only see:

As we see here we missed the commits ahead of 95613ab. You can see the HEAD with git show-ref — head but it will not show the commits in between the HEAD and the commit you checked out. So if you do git log — oneline — all you will get the whole history with the commit where the `HEAD` is right now.

Let us know if you know the better solution for this problem.

Cheers.

I completed the 9th week of my Mentorship at CNCF (Cloud Native Computing Foundation) with the FluentBit project.

WORK DONE:

1. Fixed the fill background area bug in charts.
2. Add only single counter in header instead in every metrics charts.
3. Fixed few bugs in form to enter the IP ad port
4. Remove obsolete codebase of old plugin metrics charts data.
5. Fix the background color of the charts to make UI better.
6. Look into the prototype to visualize storage metrics charts.

Planning for next week:

1. Handle the cors issue better in UI.
2. Show the y-axis label on the top of charts, currently there is no native method in chart.js for this.
3. Fix the opacity of the fill color in plugins charts

If you have some ideas what we can add or modify, feel free to ping me. You can find me on Github and Twitter.

Signing off for today, until next week.

Stay safe

:wq

I completed the 8th week of my Mentorship at CNCF (Cloud Native Computing Foundation) with the FluentBit project.

WORK DONE:

1. Added the form to ask the user to enter the IP and port from which backend data is coming.
2. Show the difference for `proc_records` metrics in output plugin.
3. Fix the time issue on x-axis of the graphs using moment

Planning for next week:

1. Tweak the form to ask the user to enter the IP and port to use localstorage to save IP and port of the endpoint.
2. Restructure the codebase to start showing graphs for `storage` metrics in the dashboard
3. Improve the UI of the dashboard including added svg and make UI fluentbit friendly.

If you have some ideas what we can add or modify, feel free to ping me. You can find me on Github and Twitter.

Signing off for today, until next week.

Stay safe

:wq

I completed the 7th week of my Mentorship at CNCF (Cloud Native Computing Foundation) with the FluentBit project.

WORK DONE:

1. Fixed the bug to render the charts even the plugins sending same data.
2. Improve the UI of the dashboard.
3. Design the prototype to ask the user to enter the IP and port from which backend data is coming.

Planning for next week:

1. Implement the form to ask the user to fill IP and Port for backend.
2. Show the difference for `proc_records` metrics in output plugin.

If you have some ideas what we can add or modify, feel free to ping me. You can find me on Github and Twitter.

Signing off for today, until next week.

Stay safe

:wq

I completed the 6th week of my Mentorship at CNCF (Cloud Native Computing Foundation) with the FluentBit project.

WORK DONE:

1. Split the charts for every metrics of every plugin pipeline is using.

2. Add the Travis CI to run the tests on the code on github.

3. Added the notification if backend is not ready or sending the data or CORS Extension is disabled.

4. Fix the logo on the header of the dashboard

Where I get stuck:

1. There is a bug if the plugin is sending same data over the time chart is not rendering

Planning for next week:

1. Fix the bug I defined above to render the charts even the plugins sending same data.
2. Improve the UI of the dashboard.

If you have some ideas what we can add or modify, feel free to ping me. You can find me on Github and Twitter.

Signing off for today, until next week.

:wq

I completed the 5th week of my Mentorship at CNCF (Cloud Native Computing Foundation) with the FluentBit project.

WORK DONE:

1. Improved the UI and fixed chart rendering bugs in Dashboard.

2. Delete the unwanted layer from the Docker Image.

3. Started rendering the graphs Right to left instead of left to right.

Planning for next week:

1. Show the difference between bytes and records of input plugin at 2 points of time in graphs instead of total values of bytes and records of input plugin
2. Improve the UI of the dashboard.

If you have some ideas what we can add or modify, feel free to ping me. You can find me on Github and Twitter.

Signing off for today, until next week.

:wq

Dockerizing an application is simple, effective, but optimizing the size of Docker Image is the tricky part. Docker is easy to use but once the application starts scaling, the image size inflates exponentially. In general, the node docker image size of the applications is over 1 GB most of the time.

Why the Size matters

1. Large docker image sizes — Bigger image size requires more space means increased expense.
2. Long build durations — It takes a longer time to push the images over the network and results in CI Pipeline delays.

Let’s Start The Optimization

Here is our demo application built using the VueJS Application.

Here is the initial Dockerfile.

FROM node:10 

WORKDIR /app 

COPY . /app 

EXPOSE 8080 

RUN npm install http-server -g 

RUN npm install && npm run build 

CMD http-server ./dist

The size of this image is:

It is 1.34GB! Whoops!

Let’s start optimizing step by step

Multi-stage builds make it easy to optimize Docker images by using multiple intermediate images in a single Dockerfile. Read more about it here. By using multi-stage builds, we can install all dependencies in the build image and copy them to the leaner runtime image.

FROM node:10 AS BUILD_IMAGE  
                                                                                      WORKDIR /app      
                                                                                  COPY . /app   
                                                                                     EXPOSE 8080      
                                                                                  RUN npm install && npm run build 
                                                                                       FROM node:10          
                                                                              WORKDIR /app        
                                                                                # copy from build image  
COPY --from=BUILD_IMAGE /app/dist ./dist                                            COPY --from=BUILD_IMAGE /app/node_modules ./node_modules   
                                                                                     RUN npm i -g http-server           
                                                                             CMD http-server ./dist

Now the size of this image is 1.24GB:

node-prune is an open-source tool for removing unnecessary files from the node_modules folder. Test files, markdown files, typing files and *.map files in Npm packages are not required at all in the production environment generally, most of the developers do not remove them from the production package. By using node-prune it can safely be removed.

We can use this to remove Development Dependencies:

After making these changes Dockerfile will look like:

FROM node:10 AS BUILD_IMAGE

RUN curl -sfL https://install.goreleaser.com/github.com/tj/node-prune.sh | bash -s -- -b /usr/local/bin

WORKDIR /app

COPY . /app

EXPOSE 8080

RUN npm install && npm run build

# remove development dependencies
RUN npm prune --production

# run node prune
RUN /usr/local/bin/node-prune

FROM node:10

WORKDIR /app

# copy from build image
COPY --from=BUILD_IMAGE /app/dist ./dist

COPY --from=BUILD_IMAGE /app/node_modules ./node_modules

RUN npm i -g http-server

CMD http-server ./dist

By using this we reduced the overall size to 1.09GB

When dockerizing a node application, there are lots of base images available to choose from.

Here we will use alpine image; alpine is a lean docker image with minimum packages but enough to run node applications.

FROM node:10 AS BUILD_IMAGE

RUN curl -sfL https://install.goreleaser.com/github.com/tj/node-prune.sh | bash -s -- -b /usr/local/bin

WORKDIR /app

COPY . /app

EXPOSE 8080

RUN npm install && npm run build

# remove development dependencies

RUN npm prune --production

# run node prune

RUN /usr/local/bin/node-prune

FROM node:10-alpine

WORKDIR /app

# copy from build image

COPY --from=BUILD_IMAGE /app/dist ./dist

COPY --from=BUILD_IMAGE /app/node_modules ./node_modules

RUN npm i -g http-server

CMD http-server ./dist

By using this Dockerfile the image size dropped to 157MB \o/

Conclusion

By applying these 3 simple steps, we reduced our docker image size by 10 times.

Cheers!

Originally published at https://itsopensource.com.

How to Reduce Node Docker Image Size by 10X was originally published in itsopensource on Medium, where people are continuing the conversation by highlighting and responding to this story.

I completed the 4th week of my Mentorship at CNCF (Cloud Native Computing Foundation) with the FluentBit project. I had a video call meeting with Eduardo Silva about what I am working on and task need to be done in next week and where I am facing the issues

WORK DONE:

1. Improved the UI and fixed chart rendering bugs in Dashboard.

2. Added the logo of Fluent Bit in dashboard.

3. Optimized the Size of Docker Image to 159 MB from 1.7GB.

4. Delete unused code and dependencies from package.json.

Planning for next week:

1. Improve the UI of the dashboard
2. Load the charts right to left including storing the data for last 20 seconds.

Many excited things coming soon to the dashboard. Stay Tuned.

If you have some ideas what we can add or modify, feel free to ping me. You can find me on Github and Twitter.

Signing off for today, until next week.

I completed the 3rdweek of my Mentorship at CNCF (Cloud Native Computing Foundation) with the FluentBit project. I had a video call meeting with Eduardo Silva about what I am working on and task need to be done in next week and where I am facing the issues

WORK DONE:

1. I started working on the showing the input plugin metrics visualization with the line charts in the dashboard.

1. I also made the dashboard docker compatible, you can install dashboard via using docker image. I will keep updating the docker image

Where I get stuck:

1. Making the live charts reactive and storing the data set in a way that it does not make the UI slow.
2. Getting the metrics value for filters and output plugin as earlier they were always null. Eduardo helped me solving this issue

Planning for next week:

1. Add the charts for filters and output plugins
2. Make the charts with respect to time (in seconds) and separate each graph with only one metrics (eg — `proc_records`) and draw it against the time in seconds.

Many excited things coming soon to the dashboard. Stay Tuned.

If you have some ideas what we can add or modify, feel free to ping me. You can find me on Github and Twitter.

Signing off for today, until next week.

:wq