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

move articles to static

Browse Source 
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
This commit is contained in:
Morumotto
2023-01-24 16:40:54 +05:30
parent 43e157885f
commit 9a88c34745
12 changed files with 40 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/posts/blogs/gsod2020-report.md
-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)
content/posts/blogs/hrt-interview-1.md
-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.