1
0
mirror of https://github.com/avinal/avinal.github.io.git synced 2026-07-04 07:40:09 +05:30

move articles to static

Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
This commit is contained in:
2023-01-24 16:40:54 +05:30
parent 43e157885f
commit 9a88c34745
12 changed files with 40 additions and 0 deletions
-60
View File
@@ -1,60 +0,0 @@
---
title: The Big Red Ants
date: 2012-02-27 22:47
tags: [ants, sav]
category: article
description: 'The Big Red Ants'
image: "/images/ants.webp"
---
# The Big Red Ants
In a bird's eye view if we see around us, ants are the common and
tiniest living entitiy seen by naked eye. One of them are the big red
ants, in my view they are unique from others in two ways, first they
live on trees and second their anteenas are too long and bent in middle,
seems like their fore legs. Their mandible (mouth) seems like eagle's
beak.
As I observed them making and reparing their nests, I concluded that
they are very laborious and intellectual. They create their nests by
binding two or more leaves (maybe up to 500) together. They stich the
leaves using a stinky white substance either excreted by themselves or
from trees. This substance is like web of spider. At first builder ants
creates an array at the blade of two leaves. Then they make ant-cranes
or ant-chain like chain of monomer to form a polymer. They catch the
leaves and pull each other to stich. After some time, the parliament of
leaves transforms into a leaf-sac called their nest. They also weave
translucent cloth like structure to cover remainings of leaf. A nest
hangs by a branch of the trees.
A nest is skillfully divided into living rooms, barracks, storehouse,
egg room and queen's room. The eggroom, lies at the center of nest to
protect from outer attack until last time. Besides that, lies queen's
room. Living rooms are sequenncly joined with eggroom. There are
different rooms for workers, food searchers etc. The partition of the
room resembles atom's electron shell, one upon another. At last barracks
are the outermost rooms, just like outermost orbit of electron. The
defence system is strongest at the nest's opening. A nest may size as
2-3 footballs and have 50 to 10000 ants. There may be more openings.
Now about their attacking and protecting skills. A solider is unique
from other ants. It is equipped with many attacking and defending
skills. Normally they do not attack. They are social insects. If someone
attacks, all other ants go inside, and soldiers come out. They spread
allover the nest. They are very sensetive and have sharp vision. If any
one of them see their enemy the stand on their hind legs, swinging,
their forelegs and anteens in their air as scolding someone. Their spit
contains formic acid, present at the end of the abdomen below the
rectum. If their nest is broken and eggs fall on ground then the ants
make a dome, like the dome of Taj mahal to save the eggs till last their
breadth. This shows their caring skills.
The most amazing is their discipline. They can easily beat a human in
race of discipline. Humans must learn from it. When two ants meet, they
touch their anteena to communicate. When they walk in a queue, they seem
like twinkling dots and dashes. I want to conclude that **All tiny
things are not really tiny. It may be as a space having infinite
mysteries one has to explore it.**
Photo Attribution : Photo by Michael Willinger from Pexels:
-62
View File
@@ -1,62 +0,0 @@
---
title: प्रेम रतन धन पायो
date: 2019-09-21 15:47
category: article
tags: [love, article, hindi]
image: "/images/fedora-night.webp"
---
# प्रेम रतन धन पायो
टूटता तारा देखना एक अलौकिक अनुभव है। हिमाद्रि के छत से आसमान कुछ ज्यादा ही करीब प्रतीत होता है । लोग सदियों से हिमालय को पूजते आयें हैं ।
दादा-दादी कहा करते थे ये जिंदा पहाड़ हैं । सारी बातें सुनते हैं लोगों की । उनके दुख दर्द दूर करते हैं, ये देवता हैं । आजकल जब रोज़ क्लास
आते जाते दूर पहाड़ों की चोटियाँ देखता हूँ तो उनकी विशालता का अनुभव होता हैं । एक पल को अगर ये मान लिया जाए की हमारी सारी धार्मिक किताबें
वो कहानियाँ हैं जो पथिक लेखकों के द्वारा लिखी गयी हैं तो सारी बातें साफ हो जाती है कि क्यूँ देवी-देवताओं ने हिमालय को अपनाया है। टूटता
तारा देखना अलौकिक है पर हिमालय की श्रेणियों से टूटता तारा देखना दैविक है । और वो कहते हैं न जिसमें न कोई तर्क हो न ही हाथों की सफाई वो
दैविक है। टूटते तारो के बारे में लोगों के बहुत सारे विश्वास हैं । कभी विभीषिका का पूर्वाभास माने जाने वाले इन टूटते तारे आज इच्छा पूरक के
प्रतीक हैं । कुछ लोगों का ये भी मानना है कि टूटते तारे दिवंगत लोगों का संकेत हैं । हिमालय की कन्दराओं में न जाने कितने ही ऋषि-मुनियों ने
तप करते हुए अपना जीवन अर्पित कर दिया । इसलिए हिमालय की पहाड़ों से टूटता तारा देखना दैविक हैं क्योंकि शायद वो तारे उन ऋषि-मुनियों की पवित्र
आत्माओं का संकेत हैं ।
प्रकृति की सुंदरता और कलाकारी हिमालय की कण-कण में झलकती है। प्रकृति ने प्रेम को भी हिमालय के जितना ही विशाल और अलौकिक बनाया है । ये एक
अलग चर्चा का विषय है कि हिमालय पहले आया या प्रेम। मैं तो प्रेम के पक्ष में हूँ । वो हर अणु-परमाणु जिन्होंने इतने बड़ा पहाड़ खड़ा किया वो सब
आपस में प्रेम से बंधे हुए हैं। ये पृथ्वी, सूर्य, चंद्रमा, आकाश-गंगा इत्यादि सब प्रेम से बंधे हुए हैं । और हिमाद्रि के छत पर मैं इसी प्रेम
के आगोश में आकर भावशून्य होकर तारों को निहार रहा था । तभी मानो सदियों की मन्नत पूरी हुई और मुझे एक टूटता तारा दिखा । आप मेरी स्थिति की
जटिलता का अनुभव इस प्रकार से लगा सकते हैं कि लोग टूटते तारे से मन्नत मांगते हैं और मैं टूटता तारा ही मन्नत में मांग रहा था । इससे पहले की
मैं पिछली जटिलता से बाहर आता की दूसरी जटिलता सामने आ पड़ी की तारा तो दिख गया पर मैं माँगूँ क्या ? और अगर आप सोच रहे की भाई पैसे मांग लो
शोहरत , नाम , शक्ति और पता नहीं क्या-क्या ? मांग तो लेता पर अगर आप मेरी जगह इसी स्थिति में होते तो शायद आपको भी ये सब याद न आता । तो मैं
एक पल को ये आकलन करने लगा की क्या कुछ ऐसा है जिसकी मुझे बहुत जरूरत है पर मेरे पास हो नहीं । और आपको पता है की गहरी सोच में जाने पर अक्सर
क्या होता है। अब वो लोग जो ये सोच रहे की भाईसाब आप हर कहानी(सच्ची घटना का विवरण वाली कहानी 😊) में सो क्यूँ जाते हैं। सच बताऊँ तो इसका
कोई सटीक जबाव नहीं है मेरे पास, पर अध्यात्म ये कहता है की जब आप सो रहे होते हैं तो आपका मन चेतना के कई स्थिति से गुजरता है। जब आप परम
चैतन्य अवस्था में होते हैं तो रहस्य, प्रतिभज्ञान इत्यादि के रास्ते खुल जाते हैं। और विज्ञान ये भी कहता है कि निद्रा के माध्यम से इस
अवस्था में जाना उतना ही अनिश्चित है जितना किसी बाला का मेरे लिए प्रेम-प्रस्ताव । सरल शब्दों में – मैं कुछ समय के लिए सो गया।
आज से ठीक 2 महीने पहले अगर ये मुझसे कोई पूछता की क्या चाहिए तुम्हें तो शायद मेरे पास जबाव होता। दोस्त तो बहुत हैं पर जब कोई ऐसा हो जो
आपके अधूरे वाक्य पूरे कर सके, कोई ऐसा जो आपकी भावनाओं को आपकी तरह समझ सके, कोई ऐसा जो आपको आपके असल रूप में पसंद करता हो । आपको लग रहा
होगा की मैं एक प्रेमिका का विवरण दे रहा हूँ, पर नहीं या शायद हाँ , मैं समझता हूँ की अधिकतर लोग प्रेमिका शब्द का प्रयोग अनुचित ढंग से करते
हैं। जहां प्रेम है वहाँ प्रेमी-प्रेमिका होंगे फिर वो भाई-बहन का रिश्ता हो या माँ-बेटे का । एक पल को सोचो तो ऊपर के विवरण के लिए कोई सबसे
सटीक उत्तर है तो वो है माँ। जब आप उन माँ-बाप जिन्होंने आपको जन्म दिया, आपका पालन-पोषण किया , आपको इस लायक बनाया कि आप इस वक़्त ये लेख पढ़
पा रहे हैं , उनको अपनी प्रेमी-प्रेमिका नहीं कह सकते तो शायद किसी और लड़के-लड़की को कहने का आपको कोई हक़ नहीं है। पर ये बात निजी समझदारी की
है और मैं माँ-बाप के बारे में बिलकुल भी बात नहीं कर रहा, इन 2-4 पन्ने में उनको चित्रित कर पाना दुष्कर है। अगर माँ है तो ये अलग व्यक्ति
क्यूँ ? लोग कहते हैं क्योंकि भगवान हर जगह नहीं हो सकते इसलिए उन्होंने माँ बनाई। पर मैं कहता हूँ माँ भी हर जगह नहीं हो सकती इसलिए भगवान ने
दोस्त बनाए और विशेष लोग भी बनाए। आज तक बहुत सारे लोग आए-गए , कई बार लगा की शायद वो विशेष व्यक्ति मिलने ही वाला है पर वो भ्रम था शायद ये
भी हो। मैं ये नहीं कह सकता की मेरी खोज पूर्ण हो गयी पर हाँ एक पड़ाव तो जरूर आ गया है। उस पहली मुलाक़ात में एक पल को ऐसा लगा मानो किसी
चमत्कारी दर्जी ने कपड़े की जगह एक पूरा आदमी सिल कर दिया हो। सब कुछ एकदम नाप के अनुरूप। शायद कई सालों के बाद मैं खुशियों का बवंडर अपने अंदर
महसूस कर रहा था। आप पूछेंगे इसमें प्रेम कहाँ है? हिमालय जितना विशाल है उतना ही गहरा भी है , यहाँ भी प्रेम गहराई में है । प्रेम का होना
जरूरी है दिखावा तो हर कोई कर लेता है। कबीर ने अपने एक दोहे में कहा है :
**बूंद समानी समूंद में , जानत है सब कोई; समूंद समाना बूंद में , बूझे बिरला कोई।**
मैं इस दोहे को प्रेम के संदर्भ में व्याख्या करना चाहूँगा। लोग बूंद हैं और प्रेम समुद्र, लोगों को प्रेम में पड़ते सबने देखा है या सुना है,
पर जो प्रेम लोगों के अंदर व्याप्त है ये हर कोई नहीं समझता। मैं उस विशेष व्यक्ति का कृतज्ञ हूँ जिसने ने मुझे इस दोहे के मूल भाव का अहसास
करवाया।
कभी-कभी डर लगता है, खोने का उसे। आजकल दुनिया में सब अनिश्चित है। कब-क्या हो जाए ये कोई नहीं बता सकता। पहले सिर्फ पृथ्वी थी फिर लोग हुए और
तब से पृथ्वी अस्थमा की मरीज है। किसी प्रसिद्ध कवि ने लिखा है :
**आज आदमी में विष इतना भर गया है, की विषधरों का वंश उनसे डर गया है,**
**कल को कहते सुनोगे , आदमी काटा और साँप मर गया है।**
ठंडी-ठंडी हवाओं ने मेरी सारी नींद उड़ा दी। प्रकृति शायद मुझे खुश करके मारना चाहती थी। आसमान ने एक बड़े काले पर्दे का रूप ले लिया था और उस
पर्दे पर दसियो उजले साँप रेंगते नज़र आ रहे थे। मानो दस सालो के टूटते तारे एक साथ दिख रहे हों और आसमान कह रहा हो – जो चाहिए, जितना चाहिए
माँग लो। और मैंने सच में माँग लिए , लगभग सब कुछ । और उसको हमेशा पास रखने की दुआ तो नहीं माँग सका , पर वो जहां रहे, खुश रहे, सलामत रहे।
-280
View File
@@ -1,280 +0,0 @@
---
title: Create the VLC User Documentation for one Mobile Port(Android)
date: 2020-12-01 23:47
modified: 2020-12-31 23:19
category: development
tags: [vlc, gsod, gsod2020]
description: 'The project was to Create the VLC User Documentation for Android
Mobile Port which was previously hosted on VLC wiki pages. The major portion
of this was to start everything from scratch including chapter separation,
section organization.'
image: "/images/day-of-cone.webp"
---
# Create the VLC User Documentation for one Mobile Port(Android)
VideoLAN is a non-profit organization that develops software for playing
video and other media formats. VLC media player (commonly known as just
VLC) is a free and Open Source cross-platform multimedia player and
framework that plays most multimedia files as well as DVDs, Audio CDs,
VCDs, and various streaming protocols built by the VideoLAN organization
and a team of volunteers. VLC for Android is a port of the VLC for
Android OS.
The project was to Create the VLC User Documentation for Android Mobile
Port which was previously hosted on VLC's wiki pages. The major portion
of this was to start everything from scratch including chapter
separation, section organization and an engaging and easy to follow for
both technical and non-technical users. The original proposal can be
found here.
## PROJECT GOALS
- Propose a new structure for documentation e.g. Chapter Separation,
Sections etc
- Proper balance between technical and non-technical descriptions to
serve all kinds of users.
- Adequate amount of screenshots in each section and other supporting
media to make documentation more appealing.
- Optimized for all Screen Sizes. Especially for Mobile Devices.
- Ease of navigation
## COMMUNITY BONDING
This period was mostly utilized for collecting more information and many
internal meetings to shape the projects and bonding with fellow writers,
developers(mentors). I got to know more about the VLC organization and
the project. We decided to create a skeleton of the project and then
follow a Issue-Merge Request-Review-Merge system to keep the commit
history clean and maintain the proper review of the work before it is
merged.
I initially proposed that the new documentation should also use the same
tools(Sphinx and GitLab Pages) because if in future we want to merge all
the documentation into a single one, it will be easier to migrate and
will provide a consistency across all documentations. Later I got to
know that this will be an independent project and may not be merged
since it solves a lot of problems. I was already familiar with the tools
so it took no time to get started.
Nicolas Pomepuy, who is the lead developer of VLC for Android was
assigned as my primary mentor and Simon Latapie as secondary mentor.
## DOCUMENTATION DEVELOPMENT PHASE
Initial Preparation I first moved my existing demo documentation to an
entirely new repository with only the skeleton at the suggestion of my
mentor. It was necessary to keep the commit history clean. The skeleton
contained the empty directories representing the chapter separation. I
got to learn “how to properly develop a project and contribute to open
source”. This was a major lesson that got me familiar with the Merge
Request and Review system.
The Development The next part was to frame the actual documentation
pages and push to the repository. Since there was a significant
time-zone difference we agreed to discuss by creating issues and
sometimes my emails. There was one meeting every fortnight to check the
process and discuss further development and blockers. Nicolas was really
helpful and patient, answering each of my big-small queries.
Work Done
<style>
table,td,th {
border-collapse:collapse;
border: 1px solid #000000;
}
</style>
<table>
<tr>
<td><strong>Documentation</strong></td>
<td><a href="https://avinal.videolan.me/vlc-android-user/">VLC for Android User Documentation </a>
</td>
</tr>
<tr>
<td><strong>Project Repository</strong>
</td>
<td><a href="https://code.videolan.org/avinal/vlc-android-user">Projects · Avinal Kumar / VLC for Android User Documentation</a>
</td>
</tr>
<tr>
<td><strong>Commits</strong>
</td>
<td><a href="https://code.videolan.org/avinal/vlc-android-user/-/commits/master">Commits · Avinal Kumar / VLC for Android User Documentation</a>
</td>
</tr>
<tr>
<td><strong>Issues/Discussions</strong>
</td>
<td><a href="https://code.videolan.org/avinal/vlc-android-user/-/issues">Issues · Avinal Kumar / VLC for Android User Documentation</a>
</td>
</tr>
<tr>
<td><strong>Merge Requests</strong>
</td>
<td><a href="https://code.videolan.org/avinal/vlc-android-user/-/merge_requests">Merge Requests · Avinal Kumar / VLC for Android User Documentation</a>
</td>
</tr>
</table>
Since the Android port of VLC can be installed on Android
Smartphones/Tablets, Android TVs, Amazon Fire Devices and Chromebooks
too, a full documentation will cover these all devices. Although these
are different form factors, the features provided on each of them is
exactly the same and the same documentation can be used for all these
devices. As of now only Smartphones/Tablets are covered. And later
additional pages will be added to reference different features/User
Interface. Regardless of this addition the current documentation can
serve a major part for all these form factors. Completed/Remaining
<table>
<tr>
<td><strong>Chapters</strong>
</td>
<td><strong>Sections</strong>
</td>
<td><strong>Status</strong>
</td>
</tr>
<tr>
<td><strong>Settings</strong>
</td>
<td>
<ul>
<li>General Settings
<li>Interface
<li>Video
<li>Subtitles
<li>Audio
<li>Casting
<li>Advanced
</li>
</ul>
</td>
<td><strong>ALL COMPLETED</strong>
<p>
<strong>FOR ALL FORM FACTORS</strong>
</td>
</tr>
<tr>
<td><strong>Video</strong>
</td>
<td>
<ul>
<li>Video Explorer
<li>Video Player
</li>
</ul>
</td>
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
</td>
</tr>
<tr>
<td><strong>Audio</strong>
</td>
<td>
<ul>
<li>Audio Explorer
<li>Audio Player
</li>
</ul>
</td>
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
</td>
</tr>
<tr>
<td><strong>Browse</strong>
</td>
<td>
<ul>
<li>Explorer
<li>Local Network
</li>
</ul>
</td>
<td><strong>ONLY SMB IN LOCAL NETWORK COMPLETED</strong>
</td>
</tr>
<tr>
<td><strong>Installation</strong>
</td>
<td>
<ul>
<li>Smartphones/Tablets
<li>Android TV
<li>Fire Devices
<li>Chromebooks
</li>
</ul>
</td>
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
</td>
</tr>
<tr>
<td><strong>User Interface</strong>
</td>
<td>
<ul>
<li>Smartphones/Tablets
<li>Android TV
<li>Fire Devices
<li>Chromebooks
</li>
</ul>
</td>
<td><strong>COMPLETED FOR SMARTPHONES/TABLETS</strong>
</td>
</tr>
<tr>
<td><strong>Support</strong>
</td>
<td>
<ul>
<li>FAQs
<li>Help
</li>
</ul>
</td>
<td><strong>IN PROGRESS</strong>
</td>
</tr>
<tr>
<td><strong>Guidelines</strong>
</td>
<td>
<ul>
<li>Contribution Guideline
<li>Screenshot Guidelines
<li>READMEs
</li>
</ul>
</td>
<td><strong>IN PROGRESS</strong>
</td>
</tr>
</table>
## CHALLENGES
The major obstacle was to get screenshots for all form factors. Since
screenshots were the major part of this documentation it was necessary
to provide proper screenshots in each chapter and with every step. For
Android TV and Smartphone this was solved by using emulators instead of
actual devices, but to emulate the actual scenario in an emulator was
sometimes very difficult. There were many occasions where I was not able
to gather the exact information about devices other than
smartphones/tables. Since all form factors share a common pool of
features, my mentor suggested that I focus on smartphones/tables. And to
create issues mentioning missing parts so that it could be solved later.
## THANKS
I want to thank my mentors for being supporting and helpful. I want to
thank every person at VLC and Google who were involved in this whole
process. Thanks and Congrats to my fellow writer Abhishek Pratap Singh.
This was a great opportunity to learn and meet awesome people. I learned
a lot about Sphinx, reStructured Text and many other things.
## ATTRIBUTION
- [Image by Tom Bigelajzen](https://images.videolan.org/images/goodies/day-of-the-cones-ex2.jpg)
-90
View File
@@ -1,90 +0,0 @@
---
title: HRT (Hudson River Trading) Systems Internship Interview Experience
date: 2021-01-04 21:47
tags: [HRT, hudsonrivertrading, interview, internship]
category: blog
image: "/images/hrt-singapore.webp"
---
# `HRT (Hudson River Trading)` Systems Internship Interview Experience
I applied for **Systems Internship - Summer 2021** back in December 2020
at [Hudson River Trading](https://www.hudsonrivertrading.com) , New
York. The internship description was: -
> We are looking for highly motivated students who are eager to learn
> and excited about systems to join us for our summer internship
> program. As a systems intern, you may have the opportunity to work on
> projects in the following areas:
>
> - Programming/scripting (Golang, Python, C++, C)
> - FOSS development
> - HPC, Cluster computing
> - System Administration
> - Linux, Debian
> - Linux-based computer security
> - Data Storage
> - Large deployment or config management
The first step was a coding test on the Codility platform. If you have
used any of the online coding platforms, this is similar. It was a
`2.5 hrs (90 mins)` test consisting of 3 questions. They let you use
`online references (documentation, man pages, etc.)` but **do not copy
the code** as it will highly reduce your chances of qualifying for this
first stage. You can choose between **C/C++**, **Python** and **Golang**
(no Java 😪).
Questions were clear and of medium level. But they were designed in such
a way that you must know the basics before you could attempt. Also, they
expected a clear and concise approach. Two of the most important points
in their instructions were: -
> - While correctness and performance are the most important factors
> for evaluation, we will take test duration into account as well.
> - Please understand that this test is meant to be challenging. A
> perfect score is not necessary to move on to future interview
> rounds, so do the best you can!
So, you must be near perfect in your approach as well as on time. I did
them kind of quickly. They will show you a summary of your submission
but not the results. It will take almost 2 weeks to get back to you for
further steps.
Next, I received a mail invitation for a telephonic interview. **This
interview will last about 45 minutes and will be technical but will not
require coding. Interview topics may include your background,
programming languages, and Unix/Linux concepts**. Once you receive this
mail you can then decide a time slot for an interview.
I was not sure what they will ask if this is not a coding interview. The
interviewer was very polite, and he was explaining the questions too.
Questions were not so tricky but practical and real-life. Since it was
**not for SDE role**, the questions were mostly related to Linux/Unix,
C++ (mainly pointers and memory), Python/Bash scripting, automation,
knowledge of tools (IDEs, Editors, System Administration Tools) and
previous experiences. The interview would often explain why he is asking
this question, this was very nice. Then some common interview questions,
why do you want to work for this role? What makes you fit for this role?
etc.
One thing that I want to point out is that the interviewer was
repeatedly checking my resume, and for the most part he did not ask
anything that was not on my resume. So, my tip is to create a nice
resume with genuine work/tool experiences. And when you are applying for
such a role, it would be helpful if you mention mathematics or other
courses that you have taken. *Do not lie on your resume*. They will
easily catch that.
The other thing is to keep your words short and clear; I was not great
at communication, but you can be. If the interviewer allows then use
examples for the things you cannot explain. I used nice examples. At
last, he gave me short feedback on how well I performed.
At last, I want to point out things I should not have done. The first
is, I did not ask much about the role, you must do this at least once.
Second, I am talkative, I do not know if the interviewer was not faking
his expressions (because he would often discuss in-depth), but not all
interviewers will be the same. So, do not talk too much, nor too less.
At last work on your communication skill, mostly how you to present
things and how to answer technical as well as behavioral questions. I
was not fluent, but my way of presentation might have saved me.
@@ -1,831 +0,0 @@
---
title: Google Summer of Code 2021
date: 2021-08-19 23:07
tags: [gsoc, FOSSology]
category: development
description: This is the final report of my Google Summer of Code 2021 at The FOSSology Project.
image: "/images/gsoc-wall.webp"
---
# Google Summer of Code 2021
<style>
.rd {color:red;font-weight:bold}
.gr{color:green;font-weight:bold}
.or{color:orange;font-weight:medium}
ul{margin-bottom:0}
</style>
## The CMake Build system
FOSSology is quite an old and mature project. The project has been using
bare metal **Makefiles**. As the project is growing with new agents and
modernization it was required to have a modern build system.
The FOSSology is a suite of well-integrated and synchronized
sub-projects (called agents) written in C, C++, and PHP. Most of the
major agents are in C, C++ and that made CMake an obvious choice for a
new build system for FOSSology. CMake is a versatile set of build, test,
and packaging tools and is the most popular choice of C/C++ developers.
CMake can be extended to create a build system for other languages too
via custom scripts.
## GitHub Actions CI/CD
<img src="/images/ci.webp"
class="float-md-right rounded border border-info ml-3 float-md-right rounded border border-info ml-3"
width="350" alt="A CI Meme" />
Since the FOSSology project moved on Github, it has used only the free
Travis CI service for OSS projects. At the time of writing Travis CI has
reduced its free tier CI services. GitHub Actions provides faster
builds. Since GitHub Actions is a fully managed service by GitHub, we
don't need to know how to scale and operate the infrastructure to run
it.
It is straightforward to use with GitHub because when we fork a
repository, the actions automatically get forked. This allows you to
test and build projects very efficiently and even run them closer to the
developer. Also, you have readily available access to the GitHub API,
making it more popular among developers.
## Improvements over previous build system and CI
The new build system and CI brings a lot of improvements and features.
The list below describes them.
- CMake enforces out-of-source builds. This was already possible with
the previous build system but not a strict requirement. This feature
keeps the source code clean and makes cleaning the build artifacts
easy. (Just remove the build folder :)
- One of the major improvements over the previous build system is faster
build times. CMake generates parallel build-enabled configurations for
all generators. In our tests, the new build system is at least twice
as fast as the previous one. With further improvement in
configuration, we will be able to further cut the build times.
- Previously FOSSology can only be built using *Unix Makefiles*. With
CMake, we can now use many other popular generators such as *Ninja*.
- Now it is also very flexible to choose different compilers. This will
help support more platforms and architecture in the future. As of now,
we are experimenting with Clang compilers.
- FOSSology is quite an old project and a lot of agent testing code was
written in the last decade. Initially, none of them were compatible
with the new build system, but we were able to hack most of the test
code using better-improved methods. Test times have also improved.
- Migrating from Travis CI to GitHub Actions was another big move and
for the most part, it removes the dependency on a third-party CI
service. Along with that GitHub Actions provides better build times,
tons of new features, and better integration with other GitHub
services.
## Deliverables
- Final Pull Request [#2075](https://github.com/fossology/fossology/pull/2075)
- Pull Request Branch [avinal/feat/buildsystem](https://github.com/avinal/fossology/tree/avinal/feat/buildsystem)
- Working Branch (individual commits)
- [avinal/feat/cmake-buildsystem](https://github.com/avinal/fossology/tree/avinal/feat/cmake-buildsystem)
- [avinal/feat/testing](https://github.com/avinal/fossology/tree/avinal/feat/testing)
- Project Issue [#1913](https://github.com/fossology/fossology/issues/1913)
- Project Discussion [#1931](https://github.com/fossology/fossology/discussions/1931)
- Weekly Reports
- [Personal Blog](https://gsoc.avinal.space)
- [FOSSology Official Blog](https://fossology.github.io/gsoc/docs/2021/buildsystem/)
### CMake Build System Tasks
<table>
<colgroup>
<col style="width: 7%" />
<col style="width: 23%" />
<col style="width: 15%" />
<col style="width: 15%" />
<col style="width: 30%" />
<col style="width: 23%" />
<col style="width: 38%" />
</colgroup>
<thead>
<tr class="header">
<th>#</th>
<th>Agents</th>
<th>Build</th>
<th>Install</th>
<th>Testing</th>
<th>Packaging</th>
<th>Remarks</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>1</td>
<td>adj2nest</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>2</td>
<td>buckets</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><blockquote>
<p><span class="gr">YES</span></p>
</blockquote></td>
<td></td>
</tr>
<tr class="odd">
<td>3</td>
<td>cli</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="rd">Functional</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>4</td>
<td>copyright</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>5</td>
<td>debug</td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>6</td>
<td>decider</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>7</td>
<td>deciderjob</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>8</td>
<td>delagent</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="rd">Functional</span></li>
<li><span class="rd">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>9</td>
<td>demomod</td>
<td><span class="or">YES</span></td>
<td><span class="or">YES</span></td>
<td><ul>
<li><span class="or">Functional</span></li>
<li><span class="or">Unit</span></li>
</ul></td>
<td><span class="or">NO</span></td>
<td><em>(Not Used)</em></td>
</tr>
<tr class="even">
<td>10</td>
<td>example_wc_agent</td>
<td><span class="or">YES</span></td>
<td><span class="or">YES</span></td>
<td><ul>
<li><span class="or">Functional</span></li>
<li><span class="or">Unit</span></li>
</ul></td>
<td><blockquote>
<p><span class="or">NO</span></p>
</blockquote></td>
<td><em>(Not Used)</em></td>
</tr>
<tr class="odd">
<td>11</td>
<td>clib</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>12</td>
<td>cpplib</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>13</td>
<td>phplib</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td>1 functional test needs fix</td>
</tr>
<tr class="even">
<td>14</td>
<td>maintagent</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>15</td>
<td>mimetype</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>16</td>
<td>monk</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>17</td>
<td>ninka</td>
<td><span class="or">YES</span></td>
<td><span class="or">YES</span></td>
<td><ul>
<li><span class="or">Functional</span></li>
<li><span class="or">Unit</span></li>
</ul></td>
<td><span class="or">NO</span></td>
<td><em>(Deprecated)</em></td>
</tr>
<tr class="even">
<td>18</td>
<td>nomos</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>19</td>
<td>ojo</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td>1 functional test needs fix</td>
</tr>
<tr class="even">
<td>20</td>
<td>pkgagent</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>21</td>
<td>readmeoss</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>22</td>
<td>regexscan</td>
<td><span class="or">YES</span></td>
<td><span class="or">YES</span></td>
<td></td>
<td><blockquote>
<p><span class="or">NO</span></p>
</blockquote></td>
<td><em>(Deprecated)</em></td>
</tr>
<tr class="odd">
<td>23</td>
<td>reportImport</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>24</td>
<td>reuser</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>25</td>
<td>reso</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>26</td>
<td>scheduler</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="rd">Functional</span></li>
<li><span class="rd">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td>Tests needs fix</td>
</tr>
<tr class="odd">
<td>27</td>
<td>softwareHeritage</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="even">
<td>28</td>
<td>spasht</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>29</td>
<td>spdx2</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td>1 Test failing in CI</td>
</tr>
<tr class="even">
<td>30</td>
<td>unifiedreport</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>31</td>
<td>ununpack</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="rd">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td>Unit tests needs fix</td>
</tr>
<tr class="even">
<td>32</td>
<td>wget_agent</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="gr">Functional</span></li>
<li><span class="gr">Unit</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
<tr class="odd">
<td>32</td>
<td>www</td>
<td><span class="gr">YES</span></td>
<td><span class="gr">YES</span></td>
<td><ul>
<li><span class="rd">UI</span></li>
</ul></td>
<td><span class="gr">YES</span></td>
<td></td>
</tr>
</tbody>
</table>
### GitHub Actions CI Tasks
| # | CI Tasks | Status |
|-----|-----------------------------------------|----------------------------------------------------------|
| 1 | <span class="gr">build</span> | Added Ubuntu 20.04 GCC 8, 9 and Clang, GCC 7 not working |
| 2 | <span class="gr">c/cpp unit test</span> | Added, delagent, scheduler and ununpack not working |
| 3 | <span class="gr">phpunit tests</span> | Added, delagent and scheduler functional not working |
| 4 | <span class="rd">cahching</span> | Not implemented |
| 5 | <span class="rd">source install</span> | Not implemented |
(<span class="gr">GREEN</span>: COMPLETED, <span class="rd">RED</span>:
INCOMPLETE, <span class="or">ORANGE</span>: NOT NEEDED/DEPRECATED)
## How does it work and how to use it?
The new build system retains the modular and hierarchical structure of
the previous build system. On the other hand, the new build system
provides several new flags to control the build. The new build system
forces out-of-source build instead of the previous in-source builds.
This keeps the source clutter-free and reduces the chance of
accidentally deleting source files. *Testing still needs some in-source
artifacts, this will be solved once all the tests are fixed according to
the new build system.*
Each agent is a complete CMake sub-project with its independent
configuration for building, installing, and testing. That means a single
agent can be built and installed separately and even removed from the
default build without breaking other builds. The directory structure is
as below.
```bash
.
├── build # temporary directory for build artifacts
├── cmake # CMake modules for FOSSology
│ ├── FoPackaging.cmake # CMake Packaging configurations
│ ├── FoUtilities.cmake # Custom CMake utilities
│ ├── FoVersionFile.cmake # VERSION version.php CMake template file
│ ├── SetDefaults.cmake # CMake defaults for this project
│ ├── TestInstall.make.in # Template makefile for install during tests
│ └── VERSION.in # VERSION file template
├── src
│ ├── agent-1 # Agent sub-project
│ │ ├── agent # Agent's source code directory
│ │ │ ├── agent-source-code
│ │ │ └── CMakeLists.txt
│ │ ├── agent_tests # Agent's test directory
│ │ │ ├── Unit
│ │ │ ├── Functional
│ │ │ └── CMakeLists.txt
│ │ ├── ui # Agent's UI source code
│ │ │ ├── templates
│ │ │ └── agent-ui-code
│ │ └── CMakeLists.txt # Agent's top-level CMake configuration
: :
│ ├── other agents
: :
│ └── CMakeLists.txt # Source intermediate CMake configuration
:
├── other directories and files
:
└── CMakeLists.txt # FOSSology Top-level CMake configuration
```
The `cmake` directory contains customized CMake modules and templates
for FOSSology. This directory is required for all the operations. The
general workflow of the new build system as well as how to use it is
described below.
1. Since the new build system is still in review. You must fork
FOSSology and pull the
[#2075](https://github.com/fossology/fossology/pull/2075) pull
request branch. Once you are in FOSSology root, run these commands.
```bash
git fetch https://github.com/avinal/fossology avinal/feat/buildsystem:buildsystem
git checkout buildsystem
```
2. The first step towards building is to create a temporary directory
for storing intermediate files and build artifacts. By convention we
use a directory named `build`, but you can use any name. (**NOTE:
For testing do not use other names**)
```bash
mkdir build
cd build
```
3. In the next steps, we will configure the CMake project and generate
the required configurations. You can use several flags to control
the build. Given below are the flags available for this project.
<table style="width:99%;">
<colgroup>
<col style="width: 34%" />
<col style="width: 43%" />
<col style="width: 20%" />
</colgroup>
<thead>
<tr class="header">
<th>CMake Flags</th>
<th>Description</th>
<th>Default</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><strong>-DCMAKE_INSTALL_PREFIX=&lt;path&gt;</strong></td>
<td>Sets the install prefix.</td>
<td><code>/usr/local</code></td>
</tr>
<tr class="even">
<td><strong>-DAGENTS="agent1;agent2..."</strong></td>
<td>Only configure these agents.</td>
<td>ALL AGENTS</td>
</tr>
<tr class="odd">
<td><strong>-DOFFLINE=&lt;ON/OFF&gt;</strong></td>
<td>Controls vendor generation, ON=NO</td>
<td><strong>OFF</strong></td>
</tr>
<tr class="even">
<td><p><strong>-DCMAKE_BUILD_TYPE=&lt;type&gt;</strong></p>
<blockquote>
<ul>
<li>Controls build type aka level optimisation</li>
</ul>
</blockquote></td>
<td><ul>
<li><code>Debug</code></li>
<li><code>Release</code></li>
<li><code>RelWithDebInfo</code></li>
<li><code>MinSizeRel</code></li>
</ul></td>
<td><code>Debug</code></td>
</tr>
<tr class="odd">
<td><strong>-DTESTING=&lt;ON/OFF&gt;</strong></td>
<td>Controls testing config generation</td>
<td><blockquote>
<p><strong>OFF</strong></p>
</blockquote></td>
</tr>
<tr class="even">
<td><strong>-DMONOPACK=&lt;ON/OFF&gt;</strong></td>
<td>Package adj2nest and ununpack seperately</td>
<td><strong>OFF</strong></td>
</tr>
<tr class="odd">
<td><strong>-GNinja</strong></td>
<td>Use Ninja instead of Unix Makefiles</td>
<td><em>Unix MakeFiles</em></td>
</tr>
</tbody>
</table>
There are lots of inbuilt CMake command-line options you can see
them in the official
[documentation](https://cmake.org/cmake/help/v3.10/manual/cmake.1.html).
Once you have chosen your flags we can now configure the project
using the following commands.
```bash
# From build folder
cd <name-of-build-directory>
cmake <flags> ..
```
4. The next step is to build the project. You can use parallel jobs to
build faster. For more options you can type `cmake --help` or
`make --help` or `ninja --help`.
```bash
# Common build command for all generators,
# Default number of parallel builds depends on generator used
cmake --build . --parallel <no-of-processes>
# For Unix Makefiles, no parallel build by default
make -j <no-of-processes>
# For Ninja, 8+ parallel build by default (depends on system)
ninja -j <no-of-processes>
```
5. Installing is also as easy as building. You can choose to install
only certain components even if you have built the whole project. If
you directly invoke the install command without building the
project, it will automatically build the project first.
```bash
# For Unix Makefiles
make install
# For Ninja
ninja install
```
6. While testing has some issues, most of the testing is working fine.
For now, you must build and run any test from the FOSSology root
directory only. You can choose to configure a single agent if you
want to test one agent only. See `ctest --help` for controlling test
runs.
```bash
# Common testing command
ctest --parallel <no-of-processes>
# For Unix Makefiles
make test
# For Ninja
ninja test
```
7. You can package FOSSology, the packaging currently lacks copyright
and conf files. But for testing purposes, you can use the following
commands. Similar to installing, if you run the package command
without building the project, it will automatically build the
project first. See `cpack --help` for more packaging options.
```bash
# Common testing command
cpack
# For Unix Makefiles
make package
# For Ninja
ninja package
```
## Known Issues and Drawbacks
Although the transition from Makefiles to CMake and Travis CI to GitHub
Actions is almost complete and working as expected. But it is not free
of drawbacks and issues. This section outlines the known issues at the
time of writing.
![A Bug Meme](https://imgs.xkcd.com/comics/conference_question.png)
- Coverage builds may fail with linking errors.
- Packaging prefix is the same as the install prefix. This requires the
developer to set the install prefix manually before packaging to
produce packages with the correct directory structure.
- Testing and packaging must be used from the FOSSology root directory.
Not doing so may or may not configure the project as intended.
- Previously tests were written hardcoded for the Makefiles. But new
build system requires all artifacts to be generated in a separate
directory. This required me to add symbolic links wherever a generated
script or file is expected. Tests can still leave some artifacts
inside source folders.
- There is no easy way to install a particular agent from the FOSSology
root directory.
- Packages don't contain copyright, readme, and license files. CMake
doesn't provide a way to include these files. This is being tracked by
issue
[#21832](https://gitlab.kitware.com/cmake/cmake/-/issues/21832).
- While packaging the symbolic links may or may not be dereferenced and
hence results in copying the folder too in the target directory.
- Running tests locally may require switching to `fossy` user.
- While configured for testing, it may give permission errors.
- Scheduler, Ununpack, and Delagent unit and functional tests are not
working. I have added an issue
[#2084](https://github.com/fossology/fossology/issues/2084) to track
the progress on fixing these tests.
- CMake doesn't generate uninstall targets. The closest thing to
uninstall is [this snippet](https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake).
This will be later added to the FOSSology.
## Challenges Faced
While this whole project was challenging, some aspects of it were
unforeseen and more challenging. When I decided to go on with this
project I just had enough CMake knowledge to write a configuration for a
very small project. I had never used CMake on this big scale. On the
other side, the FOSSology community is largely unknown to CMake so for
all of us it was learned, practiced, and implement. With support from
mentors, I was able to overcome this challenge with flying colors.
The other challenge was to understand the old build system, how they are
all connected and what is the flow. The complexity can be imagined by
the fact that the most of code and configurations were written in the
decade before the last decade and haven't changed much since then.
The most challenging task was to make tests work with the new build
system. Since tests were mostly hardcoded and the new build system
refactored many of the files and directory, the tests were failing
initially. The testing part took me the most time. All thanks to my
mentor Gaurav, I was able to hack them to suit the
new build system.
## Related Resources and Links
- Fix FOSSology agent tests issue
[#2084](https://github.com/fossology/fossology/issues/2084)
- feat(CI): Migrate API docs generation and deployment to GitHub Actions
pull request
[#1917](https://github.com/fossology/fossology/pull/1917)
- feat(CI): Migrate Static Checks and Analysis to GitHub Actions from
Travis CI [#1919](https://github.com/fossology/fossology/pull/1919)
## Future Development Plans
There is a lot to do with the new build system and CI and it will
probably take a year or to reach a maturity point. I was able to meet
most of the goals but some of them are remaining.
- Fix the tests, probably renovate them from the ground up.
- Find a hack for packaging problems.
- Improve and optimize the build.
- Modernise the source code, remove old, bloated code and replace them
according to new standards.
## What did I learn from this project?
This Google Summer of Code was the busiest time of my life for all good
reasons. I learned a lot about license compliance and how it all works
in the software industry. The next big thing is CMake. As I mentioned I
was just a novice user of CMake. Now I am confident that given any other
large project I will be able to migrate it/improve it. I got to learn
PHP, of which I did not know a single word before GSoC. And finally, I
learned about packing and testing. I had these courses but implementing
them myself and fixing them was a wholesome experience.
Other than that I improved on my communication and presentation skills.
Collaborating with fellow participants was one of the great things that
happened during GSoC.
## Acknowledgments
Google Summer of Code is the best thing that has happened to me this
year so far. Although there are numerous people to say thanks to, I want
to mention key people who were my motivation and support during this
period.
First of all, I want to thank and appreciate my mentors [Gaurav
Mishra](https://github.com/GMishx), [Michael C.
Jaeger](https://github.com/mcjaeger), [Anupam
Ghosh](https://github.com/ag4ums), and [Shaheem Azmal M
MD](https://github.com/shaheemazmalmmd). Without the help and support
from them, all this would not have been possible. They are very polite,
knowledgeable, and helpful.
Finally, I want to thank, my family and friends. I got to meet many
awesome developers as my fellow participants from around the world, I
wish we will do more collaboration in the future.
@@ -1,119 +0,0 @@
---
title: I am loving it! RedHat
date: 2022-02-25 20:47
category: development
tags: [kubernetes, redhat, docker, golang, tekton, openshift, intern]
description: I made it to the Red Hat as a DevTools intern. This post is about onboarding and how I prepared myself for working on the actual project.
image: "/images/fedora-wall.webp"
---
# My internship at Red Hat
I have been contributing to open source for the last 3 years and Red Hat
was one of the companies that I was very fond of. I must say all my
contributions and consistency paid off, and I made it to the Red Hat as
a DevTools intern. This post is about onboarding and how I prepared
myself for working on the actual project.
On the first day of my internship, I met two amazing teammates
[Saytam](https://github.com/) and [Utkarsh](https://github.com/). We
were also introduced to a Senior Software Engineer [Piyush
Garg](https://github.com) who later mentored us. The initial few
meetings were more on the introduction and what to learn topics. Before
I jump into more details let me explain first what does a **DevTools
Developer/Engineer** do?
## What does a DevTools Developer/Engineer do?
From [MDN Web
Docs](https://developer.mozilla.org/en-US/docs/Glossary/Developer_Tools)
**Developer tools (or "development tools" or short "DevTools") are
programs that allow a developer to create, test, and debug software.**
At RedHat, a lot of open source developer tools of industry standards
are developed. There are many, OpenShift, Tekton, CodeReady containers,
and many more.
## Learning on the Go
There was a lot of learning and still a lot to learn. In a meeting with
my manager Pradeepto Bhattacharya, I was told that I will be working on
TektonCD or OpenShift Pipelines, and both of them require a sound
knowledge of Golang, CI/CD, Containers, Docker, and Kubernetes. I was
familiar with CI/CD, containers, and Docker but never used Golang and
Kubernetes. We were provided plenty of good resources and my teammates
also helped with many awesome resources. I am listing all the resources
with their category.
### Go Programming Language
One of Golang's biggest advantages is that it offers the clarity and
ease of use that other languages lack. Golang's advantages make it easy
for new programmers to quickly understand the language and for seasoned
veterans to easily read each other's code.
- [Official Go Documentation](https://go.dev/doc/) - *Start from here*
- [Go by Example](https://gobyexample.com/) - *bite-size examples for
most of the golang features*
- [Golang tutorial series -
GOLANGBOT.COM](https://golangbot.com/learn-golang-series/) - *in-depth
tutorial of golang*
- [Effective Go](https://go.dev/doc/effective_go) - *writing good golang
programs*
- [The Go Playground](https://go.dev/play/) - *official online golang
ide*
- [The Go Programming Language - Book](https://www.gopl.io/) *for
learning advanced level golang*
- [Golang Tutorial for Beginners | Full Go Course - TechWorld with
Nana](https://youtu.be/yyUHQIec83I) *if you prefer video tutorials, I
don't :)*
### Docker
Docker takes away repetitive, mundane configuration tasks and is used
throughout the development lifecycle for fast, easy, and portable
application development - desktop and cloud. Docker's comprehensive
end-to-end platform includes UIs, CLIs, APIs, and security that are
engineered to work together across the entire application delivery
lifecycle.
![The Docker Architecture](/images/docker-architecture.webp)
- [Docker and Containers -
Katacoda](https://www.katacoda.com/courses/docker) *interactive
lessons on docker and containers*
- [Docker for beginners](https://docker-curriculum.com/)
- [Docker Tutorial for Beginners | TechWorld with
Nana](https://youtu.be/3c-iBn73dDE) *video tutorial*
### Kubernetes
![Kubernetes tech](/images/kubernetes-meme.webp)
**Kubernetes** is the Greek word for a ship's captain. We get the words
Cybernetic and Gubernatorial from it. The Kubernetes project focuses on
building a robust platform for running thousands of containers in
production.
- [Learn Kubernetes -
Katacoda](https://www.katacoda.com/courses/kubernetes) *interactive
lessons with kubernetes*
- [kube by example](https://kubebyexample.com/) *learn by doing*
- [Kubernetes Tutorial for Beginners](https://youtu.be/X48VuDVv0do)
*video tutorial*
## *Not so Minimal* Tekton Server
In late January, we were asked to implement our learnings and deep dive
into Kubernetes and TektonCD through an assignment project. Soon we
realized that whatever we were learning so far was not even close to
what we were going to implement. We were given a document containing the
requirements of the applications we were supposed to create along with
all the documentation and architectural diagrams.
The application was called **Minimal Tekton Server**. It is a set of
three different applications, i.e a server, a CLI, and a dashboard. In
short, this application is supposed to *listen to custom resources being
created and then transfer the request to Tekton API to create the
corresponding resource on the OpenShift/Kubernetes cluster.*
So are you interested in how it went? Please follow up with my [next
blog](https://avinal.space/posts/development/lovely-dangerous-things-redhat.html).
@@ -1,213 +0,0 @@
---
title: Developing Minimal Tekton Server
date: 2022-02-27 20:47
modified: 2022-03-07 22:47
category: development
image: "/images/development.webp"
tags: [tekton, go, kubernetes, openshift, redhat, intern, golang, openshift-pipelines]
description: 'This blog is a descreptive account of the development of Minimal Tekton Server. This is highly technical in nature, so please make sure that you have sufficient knowledge about Golang, Docker, Kubernetes and TektonCD. You can refer to my [previous blog]("https://avinal.space/posts/development/i-am-loving-it-redhat.html") to know about these topics.'
---
# Developing Minimal Tekton Server
This blog is a descreptive account of the development of Minimal Tekton Server.
This is highly technical in nature, so please make sure that you have sufficient
knowledge about Golang, Docker, Kubernetes and TektonCD. You can refer to my
[previous blog]("https://avinal.space/posts/development/i-am-loving-it-redhat.html")
to know about these topics.
As mentioned in my last blog, we were given to implement an application
named **Minimal Tekton Server**. The problem statement reads:
> We will be designing and implementing an application that will be
> talking to Tekton APIs to create resources on a Kubernetes/OpenShift
> Cluster. The application will expose some fields of the Tekton
> Resources which the user will provide and then this application will
> create Tekton resources by talking to Tekton APIs available on the
> cluster to create the resources based on the user-provided fields.
There are three parts in this project for the application and two more
parts for the CI/CD using TektonCD and Kubernetes/OpenShift. I will go
through each part descriptively and try to explain what we did.
## The Architecture of MKS
The first task in the development of the Minimal Tekton Server was
creating its architectural diagram. Our first diagram was trash compared
to the final diagram. Yeah, we learned. I will be explaining our
final(obviously) architectural diagram and try to make some sense out of
band-aids and duct tapes.
<img src="/images/mks-architecture.webp"
class="img-fluid my-3 img-fluid my-3" alt="The MKS Arhitecture" />
Let me start with explaining **What are MKS Resources?**. I hope you
know at least tidbits about Kubernetes and by the definition: *A
resource is an endpoint in the Kubernetes API that stores a collection
of API objects of a certain kind; for example, the built-in
:code:\`pods\` resource contains a collection of Pod objects.* But
developers soon realized that these in-built resources were not enough
for the ever-growing applications of Kubernetes. Here [custom
resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
comes into the picture. *A custom resource is an extension of the
Kubernetes API that is not necessarily available in a default Kubernetes
installation.* To define a custom resource we use something called
[Custom Resource
Definition](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
So MKS Resources are such custom resources that correspond to the
TektonCD custom resources.
<img src="/images/venus-flytrap.gif"
class="float-md-right ml-3 float-md-right ml-3" width="250"
alt="A venus flytrap engulphing an insect." />
Let us now focus on the box containing `Controller` and `API server`.
The controller can be said as a stimulus-response mechanism. Take the
analogy of a Venus Flytrap plant. The trap is initially open. There are
`trigger` hairs on the inside of the trap. Once an insect is detected,
there is a change of state and the trap closes in a blick on the eye.
The controller works the same way. It listens for the change in the
state of the MKS resources and immediately transfers the request to the
Tekton API to reflect the change in the corresponding Tekton resources.
The changes can be creation, deletion, or updating. The API server
ensures that there is a working connection between our controller and
the Tekton API.
MKS Server also exposes APIs to introduce a change of state in the MKS
resources. In technical terms these are called `verbs`. There are five
such verbs that we have exposed: `create`, `update`, `get`, `delete`,
and `list`. They can be utilized by a REST client, or in our case **MKS
CLI** to introduce desired change. The MKS command-line interface
provides commands and subcommands to do the desired tasks.
Whenever there is a change in the state, there is a logic running inside
the controller to react on that and that also affects our database. We
store four datapoints in our database: `created`, `deleted`,
`completed`, and `failed`. They tell us about the current statistcs of
our MKS resource using a single-page web app called **MKS Dashboard**
(or UI).
This was about the architecture of the Minimal Tekton Server. Let us
jump into more technical stuff.
## How to implement a CRD controller?
During this assignment, something that took the most time and effort was
the implementation of a controller for our custom resources. This isn't
very hard if you go by the rules and do the things according to the
well-defined documents and blogs since this is a standard step in the
implementation of any custom resource controller. But did we follow the
rules? Hell no! But this time, let us go step-by-step.
1. The first step is to define a `CustomResourceDefinition` for our custom
resource. Let us define a CRD called `spacetime`. To do this you can write a
YAML file like below.
```yaml
# file: spacetime-crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# name must match the spec fields below, and be in the form: <plural>.<group>
name: spacetimes.example.com
spec:
# group name to use for REST API: /apis/<group>/<version>
group: example.com
# list of versions supported by this CustomResourceDefinition
versions:
- name: v1alpha1
# Each version can be enabled/disabled by Served flag.
served: true
# One and only one version must be marked as the storage version.
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
message:
type: string
# either Namespaced or Cluster
scope: Namespaced
names:
# plural name to be used in the URL: /apis/<group>/<version>/<plural>
plural: spacetimes
# singular name to be used as an alias on the CLI and for display
singular: spacetime
# kind is normally the CamelCased singular type. Your resource manifests use this.
kind: SpaceTime
# shortNames allow shorter string to match your resource on the CLI
shortNames:
- st
```
You can learn more about the fields and options
[here](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
The CRD that we defined above corresponds to the `CustomResource` given
below. Once you apply the above file you will be able to see the
`spacetime` custom resource on your Kubernetes/OpenShift cluster.
```yaml
# file: spacetime-cr.yaml
apiVersion: spacetimes.example.com/v1alpha1
kind: SpaceTime
metadata:
name: spacetime-cr
spec:
message: "Hello from space!"
```
Apply them using the following commands:
```bash
kubectl apply -f spacetime-crd.yaml
kubectl apply -f spacetime-cr.yaml
```
1. Once we have defined our custom resources, we need to define the
types that will correspond to this custom resource definition. This
can be done using `k8s.io/apimachinery/pkg/apis/meta/v1` package
written in golang. Did I tell you that this is all in golang? Well,
now you know. Create a package structure for a golang project and
add the definition of the type as given below.
```bash
mkdir -p pkg/api/spacetime/v1alpha1
touch pkg/api/spacetime/v1alpha1/{spacetime_types,register,doc}.go pkg/api/spacetime/register.go
```
Add the following content to the corresponding files.
```go
// file: /pkg/api/spacetime/v1alpha1/spacetime_types.go
package v1alpha1
import (
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)
type SpaceTime struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec SpaceTimeSpec `json:"spec"`
}
type SpaceTimeSpec struct {
Message string `json:"message"`
}
type SpaceTimeList struct {
metav1.TypeMeta `json:",inline"`
metav1.ListMeta `json:"metadata"`
Items []SpaceTime `json:"items"`
}
```
### Attribution
- Photo by [Luca Bravo](https://unsplash.com/@lucabravo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/XJXWbfSo2f0?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).
-211
View File
@@ -1,211 +0,0 @@
---
title: How I implemented WakaTime embeddable Coding Graph GHA?
date: 2021-02-02 21:47
tags: [wakatime, github-action, coding]
category: development
image: "/images/waka.webp"
description: 'If you use WakaTime to track your coding activity. You can add that to
your README as a bar graph or embed it in your blog/portfolio. Just add this
action to any of your repositories and there you have it.'
---
# How I implemented WakaTime embeddable Coding Graph GHA?
If you use WakaTime to track your coding activity. You can add that to
your README as a bar graph or embed it in your blog/portfolio. Just add this
action to any of your repositories and there you have it.
## Implementation Details
This GitHub Action is divided into three parts. I didn't want to use
Docker but it seems it doesn't work well without it. Let dive a little
into technical details. Three parts are as below.
1. [main.py](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py)
python script. This script contains many procedures.
- [Getting JSON data file via WakaTime
API](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py#L52)
```python
def get_stats() -> list:
...
return data_list
```
This function parses the JSON file received and scraps out the useful
data as a list of lists. Data scraped are language list, time spent on
each language, percentage of the time, start date, and end date. For
this action, I have limited the number of languages to 5 however it
should be very easy to increase that number.
- [Setting the
Timeline](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py#L13)
```python
def this_week(dates: list) -> str:
...
return f"Coding Activity During: {week_start.strftime('%d %B, %Y')} to {week_end.strftime('%d %B, %Y')}"
```
The start date and end date scraped in the last function are used here
to set the timeline. Because date in JSON is provided in UTC as below
:
```json
date: "YYYY-MM-DDTHH:MM:SSZ"
```
I striped it to simple dates only. We can set them manually by taking
the current time from the system. But that method is flawed. But this
method ensures that JSON was received latest and the request was
successful. Any anomaly will point to a failure in request.
- [Creating a bar
graph](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/main.py#L21)
```python
def make_graph(data: list):
...
savefig(...)
```
Lastly, it is time to generate the graph and save them as an image.
This function uses the data scraped in the first step. Creating a bar
graph using matplotlib is easy.
Decorating was a bit difficult. I wanted this graph to merge with
GitHub's look so I chose to color the bar as GitHub colors the
languages. That data is stored as colors.json. Many of the languages have
slightly different spelling in GitHub as compared to WakaTime. So some
languages are shown in default color. That can be improved if we
notice that language and change its color manually. Lastly, the graph
is saved both as SVG and PNG. SVGs are better to put on a responsive
page.
2. [entrypoint.py](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/entrypoint.sh)
shell script. This shell script clones the repository copies the
image and pushes changes to the master. There were several problems.
First of all authentication. This was solved by using a remote
repository address using GitHub Token. And it seems that GitHub
doesn't allow to commit without a username and email. So I used
**github-actions** bot email.
```bash
remote_repo-"https://${GITHUB_ACTOR}:${INPUT_GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git"
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git config user.name "GitHub Actions"
```
`41898282` is the id assigned to the github-actions bot. Don't ask
where I found them 🙂.
Another problem was to separate repository name from combined
*username/repository-name* provided by `${GITHUB_REPOSITORY}`. GitHub doesn't
provides a direct way to get just the repo name. We used *Internal
Field Separator*. It returns an array and works similar to `split()`
command in Python and Java.
```bash
# '/' is the seperator
IFS-'/' read -ra reponame <<< "${GITHUB_REPOSITORY}"
# returned {username, repository}
repository-"${reponame[1]}"
```
After that, all other commands are pretty straight. Commit the added
files and push them.
3. [Dockerfile](https://github.com/avinal/Profile-Readme-WakaTime/blob/master/Dockerfile)
**IMPORTANT** It took a lot of time to reach this state 🥱. This is
where all the magic happens. I am running <span
class="title-ref">ubuntu:latest</span> inside the container. I first
update the distribution. Then install the required python packages.
Lastly, I invoke the python script and shell script.
There was an almost impossible problem, I searched hundreds of posts
that *how can I access the generated files inside Docker container*, but
no luck. But at last, I found a workaround(obviously otherwise you
wouldn't be reading this by now 🤣) each command is run in a separate
virtual sub-container. As the command ends its output is also lost but
not when you club multiple commands together. At least not until every
command is finished. The generated files are available to the next
clubbed process. I did that by combining the python script run and shell
script run.
```dockerfile
CMD python3 /main.py && /entrypoint.sh
```
This part is the smallest yet took the most time and tries while
developing this action.
## How to use this GitHub Actions?
1. First get your WakaTime API Key. You can get it from your
[WakaTime](<https://wakatime.com>) account settings.
2. Save WakaTime API Key to Repository Secret. Find that by clicking
the Settings tab. Keep the name of the secret as
**WAKATIME_API_KEY**.
3. Add the following line in your README.md of your repo.
```html
<img src="https://github.com/<username>/<repository-name>/blob/<branch-name>/images/stat.svg" alt="Alternative Text"/>
Example: <img src="https://github.com/avinal/avinal/blob/main/images/stat.svg" alt="Avinal WakaTime Activity"/>
```
> You can use this method to embed in web pages too. **Do not use the
> markdown method of inserting images. It does not work sometimes.**
4. Click the **Action** tab and **choose to set up a workflow
yourself**.
5. Copy the following code into the opened file, you can search for
**WakaTime Stat** in the marketplace tab for assistance.
```yaml
name: WakaTime status update
on:
schedule:
# Runs at 12 am '0 0 * * *' UTC
- cron: "1 0 * * *"
jobs:
update-readme:
name: Update the WakaTime Stat
runs-on: ubuntu-latest
steps:
# Use avinal/Profile-Readme-WakaTime@<latest-release-tag> for latest stable release
# Do not change the line below except the word master with tag number maybe
# If you have forked this project you can use <username>/Profile-Readme-WakaTime@master instead
- uses: avinal/Profile-Readme-WakaTime@master
with:
# WakaTime API key stored in secrets, do not directly paste it here
WAKATIME_API_KEY: ${{ secrets.WAKATIME_API_KEY }}
# Automatic github token
GITHUB_TOKEN: ${{ github.token }}
# Branch - newer GitHub repositories have "main" as default branch, change to main in that case, default is master
BRANCH: "master"
# Manual Commit messages - write your own messages here
COMMIT_MSG: "Automated Coding Activity Update :alien:"
```
6. Please wait till 12 AM UTC to run this workflow automatically. Or
you can force run it by going to the Actions tab. Or you can add the
following lines under `on:` to run with
every push. Search for 12 AM UTC to find the equivalent time in your
time zone.
```yaml
on:
push:
branches: [ master ]
schedule:
- cron: '1 0 * * *'
```
## My Coding Activity
![Avinal's GitHub stats](https://raw.githubusercontent.com/avinal/avinal/main/images/stat.svg)
-96
View File
@@ -1,96 +0,0 @@
---
title: Move WSL 2 Safely to another Drive
date: 2020-12-31 19:07
tags: [wsl, wsl2]
category: development
description: 'It is real pain when you have small SSD and Windows Subsystem for Linux
(WSL) is growing exponentially in size. There is no easy way to move the
WSL installation to another drive. Here in this blog I will discuss how
to tackle this problem with bite size steps.'
image: "/images/windows-wsl2.webp"
---
# Move WSL 2 Safely to another Drive
It is real pain when you have small SSD and Windows Subsystem for Linux
(WSL) is growing exponentially in size. There is no easy way to move the
WSL installation to another drive. Here in this blog I will discuss how
to tackle this problem with bite size steps.
1. Open a PowerShell or Command Prompt with *Admin* access. For this you can
use WinKey + X shortcut and select **Windows PowerShell(Admin)**.
2. Check if the WSL 2 installation you are planning to move is is
currently running/stopped.
```powershell
PS C:\\Users\\Avinal> wsl -l -v
PS C:\\Users\\Avinal>
NAME STATE VERSION
* Ubuntu Running 2
Kali Stopped 2
```
3. If its running then you must stop the particular WSL distribution.
(*Ubuntu* used as example)
```powershell
PS C:\\Users\\Avinal> wsl -t Ubuntu
```
4. Export to some folder. (Here exporting *Ubuntu* as *ubuntu-ex.tar*
to *Z:wsl2*)
```powershell
PS C:\\Users\\Avinal> wsl --export Ubuntu "Z:\\export\\ubuntu-ex.tar"
```
5. Unregister previous WSL installation
```powershell
PS C:\\Users\\Avinal> wsl --unregister Ubuntu
```
6. Create a new folder and import your WSL installation to that folder.
```powershell
PS C:\\Users\\Avinal> New-Item -Path "Z:\\wsl2" -ItemType Directory
Directory: Z:\\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 31-12-2020 21:03 wsl2
PS C:\\Users\\Avinal> wsl --import Ubuntu "Z:\\wsl2" "Z:\\export\\ubuntu-ex.tar"
```
7. Check after import is complete
```powershell
PS C:\\Users\\Avinal> wsl -l -v
PS C:\\Users\\Avinal>
NAME STATE VERSION
* Ubuntu Running 2
Kali Stopped 2
```
8. Mark one of your WSL distribution as *(default)*.
```powershell
PS C:\\Users\\Avinal> wsl -s Ubuntu
```
9. After exporting your default user will be set as
<i style="color:red">root</i> , to change it to your desired
username, run following command
```powershell
PS C:\\Users\\Avinal> ubuntu config --default-user user_name
```
10. Finally run `wsl` and you have successfully moved your WSL 2
installation to another drive.
## Attribution
- [Image](https://www.atwix.com/magento/magento-2-with-docker-for-windows-and-wsl-2/)
-1
View File
@@ -1 +0,0 @@
[{"title":"Developing Minimal Tekton Server","date":"2022-02-27 20:47","category":"development","description":"This blog is a descreptive account of the development of Minimal Tekton Server. This is highly technical in nature, so please make sure that you have sufficient knowledge about Golang, Docker, Kubernetes and TektonCD. You can refer to my [previous blog](\"https://avinal.space/posts/development/i-am-loving-it-redhat.html\") to know about these topics.","slug":"lovely-dangerous-things-redhat","image":"/images/development.webp"},{"title":"I am loving it! RedHat","date":"2022-02-25 20:47","category":"development","description":"I made it to the Red Hat as a DevTools intern. This post is about onboarding and how I prepared myself for working on the actual project.","slug":"i-am-loving-it-redhat","image":"/images/fedora-wall.webp"},{"title":"Google Summer of Code 2021","date":"2021-08-19 23:07","category":"development","description":"This is the final report of my Google Summer of Code 2021 at The FOSSology Project. One of the major improvements over the previous build system is faster build times. CMake generates parallel build-enabled configurations for all generators.","slug":"final-evaluation","image":"/images/gsoc-wall.webp"},{"title":"How I implemented WakaTime embeddable Coding Graph GHA?","date":"2021-02-02 21:47","category":"development","description":"If you use WakaTime to track your coding activity. You can add that to your README as a bar graph or embed it in your blog/portfolio. Just add this action to any of your repositories and there you have it.","slug":"wakatime","image":"/images/waka.webp"},{"title":"HRT (Hudson River Trading) Systems Internship Interview Experience","date":"2021-01-04 21:47","category":"blogs","slug":"hrt-interview-1","description":"uestions were clear and of medium level. But they were designed in such a way that you must know the basics before you could attempt. Also, they expected a clear and concise approach.","image":"/images/hrt-singapore.webp"},{"title":"Move WSL 2 Safely to another Drive","date":"2020-12-31 19:07","category":"development","description":"It is real pain when you have small SSD and Windows Subsystem for Linux (WSL) is growing exponentially in size. There is no easy way to move the WSL installation to another drive. Here in this blog I will discuss how to tackle this problem with bite size steps.","slug":"wsl1","image":"/images/windows-wsl2.webp"},{"title":"Create the VLC User Documentation for one Mobile Port(Android)","date":"2020-12-01 23:47","category":"blogs","description":"The project was to Create the VLC User Documentation for Android Mobile Port which was previously hosted on VLC wiki pages. The major portion of this was to start everything from scratch including chapter separation, section organization.","slug":"gsod2020-report","image":"/images/day-of-cone.webp"},{"title":"प्रेम रतन धन पायो","date":"2019-09-21 15:47","category":"articles","slug":"for-sunshine","description":"प्रकृति की सुंदरता और कलाकारी हिमालय की कण-कण में झलकती है। प्रकृति ने प्रेम को भी हिमालय के जितना ही विशाल और अलौकिक बनाया है । ये एक अलग चर्चा का विषय है कि हिमालय पहले आया या प्रेम। मैं तो प्रेम के पक्ष में हूँ । वो हर अणु-परमाणु जिन्होंने इतने बड़ा पहाड़ खड़ा किया वो सब आपस में प्रेम से बंधे हुए हैं। ये पृथ्वी, सूर्य, चंद्रमा, आकाश-गंगा इत्यादि सब प्रेम से बंधे हुए हैं","image":"/images/fedora-night.webp"},{"title":"The Big Red Ants","date":"2012-02-27 22:47","category":"articles","description":"As I observed them making and reparing their nests, I concluded that they are laborious and intellectual. They create their nests bybinding two or more leaves (maybe up to 500) together. They stich the leaves using a stinky white substance either excreted by themselves or from trees.","slug":"big-red-ants","image":"/images/ants.webp"}]