My first CTF

Hello everyone! I’m now in the week 10 of my academic semester.  This semester has been awesome, yet tiring. I had to get myself back to my old schedule of going to study room everyday to study. There are moments when I feel a little bored studying and doing homework and assignment. Thus, I decided that it’s time to look around and develop new hobby. I started asking questions to some seniors I know personally:

What is the one thing you wish you would do more in your university life that you think is useful?

Surprisingly, or rather to my joy, none of the answers I received is about doing homework HE HE HE. So I had several suggestions, with most of the answers relates closely to where the answer came from. Some suggested to try Competitive Programming, stating its benefits, which includes better interview skill. Some suggested me to do sports, a thing that’s totally not my cup of tea. However, during the last few months I did managed to try rock climbing, running, and Muay Thai.  One suggested me to try joining CTF and picked up some Linux skill along the way.

I then shared my findings (? studies) to my study buddy, Kevin, who happily joined me to learn CTF. Coincidentally, NTU Students’ Union held a CTF competition, which matches our timing and we felt like it is a great opportunity to try! So we register and practice hard for about a week. During that week, we spent most of our days in Starbucks or Library to  try out CTF problems and discussed about it.

During the day, we struggled against more experienced participants. There is even a team who finished all the questions during the first one hour out of the 7 hours period we had.

There are 3 main websites which we have to exploit and there are around 5 flags inside each website. Most of the CTF problems are regarding web exploitation, with only a few related to Cryptography.

In the end we managed to win the third place. I end up liking CTF type of competition more than hackathon. I did not come home as tired as I used to when I join hackathon and I feel like I think and learn a lot more during a CTF.

Attached below are some of the pictures of me during the event. Fyi, the sponsors are very generous! The prizes they stated are the full prize received by each member, e.g if the prize stated is Nintendo Switch and your group has 4 people, they will give out 4 Nintendo Switch. But, sadly, my team consists of only 2 people, since we know nobody on our interest groups who are interested in this kind of competition, thus, we only receive 2 prizes.

Sponsored Post Sponsored Post Menu More Info Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

Register now

How I ended 2018, Hello 2019!

Hi everyone! Long time no see! I haven’t blogged for a while, but I think it will be great to start back blogging.

In the beginning of August, I started my semester internship in Shopee, Sea Group to fulfil the graduation requirements. I was part of the Front End Web Team. The internship was challenging, but fun. I learnt a lot and made some new friends during the internship period. I worked most closely with the Front end Promotion Team, Minh and Van. I enjoyed the food hunting organised by Ten every week, which expand my knowledge about Singapore and turn me to be a foodie.

Around the same time, I receive happy news that I got accepted to the Facebook Open Source Mentorship with Joel Marcey as my mentor. I really enjoyed working with him and I am grateful for the flexibility and guidance he gave me throughout the program. I fixed several bugs (related to CSS and Version Control) and implemented one of the highly requested features there, the code block tabs which had just been released not long ago.

Somewhere during that period, Tanoto Foundation, my scholarship provider, held a gathering event for about 5 days in Riau, Indonesia. He flew all the scholarship recipient there to gather, meet each other, and network. It was fun and inspiring. They organized several talks and workshops on soft skills, networking, negotiating, and achieving your dreams. They even invited a Sea Games Weightlifting Gold winner to motivate us. Each session ends with a Q&A in which we can ask questions, tips & tricks from the motivators. It made me reflect on life so far and thought of planning what’s next.

November arrived swiftly and it was time for me to start applying for summer internship and prepare for the interviews. Honestly, I felt that I did not really have a strong coding interview skill since I rarely practice algorithms questions and I never join CP contest all my life. However, thanks to all my friends and NTU coach (Mr. Patrick) who were so willing to provide me mock interviews, refer me, and screen through my resume, I eventually managed to secure some internship offers and decided to spent my summer interning at Facebook. Yay! ^.^

At the end of the month, Ten (a front end dev at Shopee) and me organized a team building event. We spent the day ice-skating at Jcube and had dinner together at the Astons. December was the last month of my internship in Shopee. I felt a bit sad, since I like the team and the friends I made while I was there 😦 . Plus, I’m already used to the intern life (waking up and sleeping early). However, I also miss school a bit and need to go back to earn my degree. On my last day there, I had a mini talk about one of the internal tools I developed while I was there and our team had a big team lunch (our team has grown to be a team of 16 ppl, so it’s quite big!) where we ordered Makisan to the office.

2018 has been an awesome year with its challenges and lessons and I’m very excited to what 2019 may bring! I can’t wait to go back to school! 🙂

Outreachy Wrap Up!

14th of August marks the end of my Outreachy Internship with Mozilla. During this short 3 months, I have learnt a lot about how to network, code, write blogs ;), and generally how to engineer better. It is truly an experience I will cherish. Thanks to my wonderful mentors, Dustin, Eli, and Hassan for picking me among all other competitive participants and for all the guidance throughout the project workflow despite the huge time zone differences, the project won’t be a success without you guys.

It’s been more or less a week since the last day of my Outreachy internship. Reflecting back, I had never once imagined working with awesome bunch of people. I loved everything about my simple, beginner friendly project, Codetribute, Mozilla, Firefox and most of all, my amazing mentors and the people at Mozilla, so much so that I plan to just hang around as a volunteer even after my internship ended.

I feel like I gained a lot from this internship. I learned how to collaborate with others on a large open source project during the application period, learned how to write code with good practices, learned to google issues, and most importantly, I learned not to be afraid to ask questions, thanks to my mentors who were super patient and very kind to me. Having mentors like that and being able to learn by asking any questions I had, without any fear of judgement, is what I liked most about my internship.

While it was my Outreachy application and project that introduced me to things mentioned above and taught me how to be a good contributor, I believe it was what I choose to do after my internship ended, that will expand my education. I would like to contribute during my free time, after settling down to my new workplace, Shopee.

I have also received tons of questions through FB, Instagram, Linkedin, and emails about Outreachy, my technical skills level when I apply, how to start, what project to choose, and what criteria they use for selection. Thus, I decided to create a separate blogpost for it in the form of an Q & A while I still remember all those details. But still, I believe nothing beats checking their site regularly as it contains the most updated information (at least more updated than mine) about the administration process.

Anyway, if you are interested to apply for Outreachy, start early! Visit this Codetribute site, find issue to work on, introduce yourself, and ask to have the issue assigned to you! All the best! Ping me if you need help setting up Git, I will try my best 🙂

Before I end my post here, I’d also like to extend my thanks to the organizers of the Outreachy Program, the Outreachy coordinators at Mozilla (Lizz and Dustin) and friends who encouraged me to apply. Thank you!

Week 8 Update: Enhancements, Updating Project Data, Integrate with Bugzilla Done!

Hi guys, last week was my 8th Week as Outreachy Intern, time flies! We have received some PRs and email reply from the Project owner regarding their entry in the site. Some feedback we have received along the way are:

1. Group the Firefox related items together / reduce their amounts
2. Add language filter ability
3. Bigger text for description and smaller for tags
4. Drop the “Project Introduction” title and maybe just use the first title from the introduction. This would reduce the vertical space taken up as well.
5. Make the Expansion Panel default to close

Some project that has updated their entries are Taskcluster, MDN, Firefox UI, Telemetry Dashboard, and Sea Monkey. We are now able to find bugs and their updated project information in those project pages.

Some enhancement I do last week:

1. Add the info button beside the summary
2. Work on the display for Card which might be more suitable for mobile view
3. Close the Expansion Panel by default
4. Handle same github repository with multiple tag
5. Fix the link icon not to shrink when the text before it is too big
6. Remove wrapping from all table cell (now it wont create new line)
7. Fix table horizontal scrolling issue (when you scroll horizontally, only the table should change)

I am trying to do some experiment with the front page UI and thinking of adding some SVG to beautify the page, while doing the display bug using Card. I am also thinking of whether we should display bugs based on language query without selecting the project.

One of the UI I try to experiment with

Week 7 Updates: Filtering and Enhancement!

Hello guys! I’m back again! I returned home (Indonesia) this week while continuing my work remotely (despite the internet connection 😦 ).

This week I added several filter options like filter by tag, assignee status and component name. I do it this way because one Mozilla project might have very multiple components with totally different skill sets needed. Some may also use the tag to categorize the difficulty level or tech stack needed. The tag filter has landed, now you can click on one tag and it will filter to display bug with those tags. To deselect, click again on the tag / click a different tag.

I also work on the I’m Feeling Adventurous button that will randomly give you one task from a project. It might need more advance algorithm later on which bug it should give you, but it landed for now. I also work on several enhancements on the Error Panel (padding, text color, and button color) and make it tab-able for the project card. We try to land the bugzilla Graphql fetch soon YAY! We also try to create a guide for people to add Project’s .yaml file which is displayed throughout the site.

So I think that’s all for now! I want to try to socialize this project to the repo owners, wish me luck!

Week 6 updates: Colored page

All Hands has been amazing, I met tons of people working on things I have yet to understand during meetings, talks, or even breakfast (I followed my mentor’s advice to sit on random table)! I really like the environment where you are encouraged to ask question and everyone seems to discuss approach not only to make things work but also to make it work well, scale well, easy to maintain, and reusable by using the best approach they know at the time.

I think it has been one bad habit of mine that I try to break, that is to think ‘it is ok as long as it works’ and choose approach without considering its long term effect, especially under deadline, which results in poor, unreadable, not maintainable work, be it the problem sets I do as exercises or the code I submit for assignments, most of which become unreadable later.

The stickers I managed to secure! Does any of you know what sticker is the o-shaped circle with white filling and a little bit of red in the circumference (The one below Taskcluster’s)? Comment down below :p

After All Hands, I decided to redesign the project page and add theme to the system. Check it here. I also try to add some filters and try to pop up the question of ‘Should there be a leader board?’ in the mailing list.  On one hand, it gives motivation for contributor to continue working on bugs and serves as a reward and appreciation. Yet on another hand, it may discourage people to contribute since we only mark people that solve bugs not the one that raise it and review it. Moreover, the number of bugs one solved may not be a correct measure of how much one contribute due to difference in difficulty level and how much knowledge needed.

We also agree that title may not give enough explanation of the bug / issue and try to opt for a way to standardized a tag in the comment field in Bugzilla that shall be the explanation that contains how to get started and which repository you should look at.

I plan to do not only sorting but also filtering for the bugs. I also plan to make the display more responsive for mobile by providing choice to display Card or Table, which is nice but require wider screen.

Fifth Week as Outreachy Intern: Attending All Hands

Last week was my fifth week as Outreachy Intern. I started the week by flying for 15 hours to San Francisco to attend my first Mozilla events, All Hands and also to talk and discuss about my projects in the meetings organized by my mentor, Dustin.

I spent the first day checking in and while I wait for the Welcome Reception, I spent the day with my friend from Berkeley. On the second day, I joined several plenary and lightning talk with Taskcluster team member, coded together with the team for a few hours, then headed for dinner with the Voice and Inclusion Team. During the dinner I met my Female Mentor, Soledad from DevTools team and Josh Matthews, who is the maker of the well known BugsAhoy and currently is a Mozilla employee. On the third day, we (My mentors and I) had meeting with Josh Matthews, the BugsAhoy creator and Patrick from DevTools team to discuss about the history of BugsAhoy and how to improve the site to help more contributors find their first contributions. Then, I coded a bit and went for my team event in SF Conservatory of Flowers. On the next day, we went to a meeting with ParSys team, represented by Florian and Johann, coded a bit, and went to Taskcluster migration celebration. On Friday, I coded, biked with other intern and contributor, and went to the closing party of All Hands. So sad to say goodbyes!

Some questions raised during meetings:

1. How to guide someone after he/she had fixed a good-first-bug?
2. Should we focus on good-first-bug or mentored bugs as well? How to mark and differentiate them?
3. How to simplify the site (minimal click for everyone)? Should we have I’m feeling lucky button on all page?
4. Should we add a section for Featured / Popular projects?
5. Should we add a How-to-get-started for each project?
6. Should we add footer containing contact person of each project?
7. Should we also display assigned bugs?
8. Should we add specific tooltips for each bug, e.g for new unassigned bugs, say something like “Go for it”, for old unassigned bugs, say “Ask the mentors first to know if it is still a relevant bug to work with or pick other bugs”, etc
9. Should we display Diamond Bugs (bugs type that meant for bugs after good-first-bug) as well?
10. What type of bugs should be the default bug to be displayed?
11. Should we filter bugs based on mentor name as well (since some contributors might follow particular mentors’ bug after they know the mentor)
12. Does / will the Leader board help to increase contributor? How to filter it from Mozilla employees?
13. Should we have a bot on twitter to reward people after contributing?
14. Should we filter based on Project Technology as well, and how?
15. Is bug title enough to give description of the project?

Overall, it is really a wonderful and eye opening experience to attend All Hands. I would not be able to meet amazing people I used to meet online with, be taught tons of tips, and have long discussion with them had I did not go to All Hands.

Also, last week my PR regarding fetch from github API v4 has been merged! Now you can see issues gathered from github, e.g Test Automation’s issues (http://codetribute.netlify.com/projects/automation).

Left to right are YD (GSOC intern), Irene (Previous Outreachy Intern, now a contributor), and me! (I also have one team picture, but I’m not sure if I can post it here)

Fourth Week as Outreachy Intern: Query from GraphQL using React-Apollo

I’m back again guys!

Last week I have merged two PR, one for the search bar and another for the individual project page. I have also started designing the UI, adding color and icons. I am not so experienced in it but I hope I can finish it as soon as possible because I feel like the look of the site is an important aspect to make the site more trustworthy and appealing.
Now I am going to talk about possible ways to query using React Apollo 2.1 that I know of.

• Using ApolloConsumer‘s client:
  We can do something like this:

How to get the client from ApolloConsumer and pass it as props

Then later, we can use the client props in MyComponent to fetch data. Here is one of the examples of how to perform the query:

Graphql Query using client.query

It works as a JavaScript promise and we can add query, variables, context, and other networking options to it as well. I feel like it is a bit similar to how we usually fetch data from REST API.

• Using @graphql decorator:
  This is probably the most common one to be used.

  

  GraphQL query using @graphql decorator

  We can pass variables, context and a lot of other networking options to the options, but one thing that I think is lacking is passing props to the query itself, which in this case is the bugsQuery.

• Using <Query> Component:
  I think it is the newest feature provided by React Apollo, you can check on their documentation on how to switch from @graphql decorator to be using this Component. Their docs also cover some special use cases, like if the user previously uses compose then they can use nested Query component to perform similar operation, etc. In this Query Component, I can make the query to be a function that takes props as parameters and return the query based on the parameters.

  

  GraphQL query using Query Component

All in all, I feel like switching from one way to another will not be very hard as they all have similar arguments, however, I do need some time to read the documentation to adjust the options parameters as they can have different placement / type. I hope I can be a faster documentation reader as time passes by as it might save a lot of time if you can quickly know which part you need to read, navigate to the part that you need and understand it shortly after.

Another thing I discover is that even though GraphQL is designed to have one endpoint, you can actually combine two client to get your data from within one ApolloProvider. It is done by using split. Later on, when you want to fetch data using either of the approach above, you can select one of the client by using context which you can put in the options if you use @graphql, as attribute if you use  <Query> component, and as parameters if you use ApolloConsumer‘s client.

In my project, I use GitHub v4 API that utilize GraphQL and sometimes I wonder how they can limit user access based on the token we generated since we all use one endpoint to fetch the data. I will try to find sources about it later I guess.

I also managed to read a book about React called The Road To Learn React during the weekend. It was recommended by one question I read on Quora and since I love reading then why not. I will talk about it on later posts maybe, stay tuned!

Third Week as Outreachy Intern

Hello guys!

I can’t believe that two weeks of my Outreachy internship has passed, time flies real fast!

Last week, I start working on querying bug from Github API v4, while fixing bugs and making improvement in other open Pull Request.

Conflicting CSS Classnames on Production Build

One challenge I faced is conflicting CSS classnames on Material UI, which only happen on production build. It causes the display to be broken in the deploy preview, e.g: it appears as if Card is on top of Paper while in the class, I don’t declare any Paper. However, this issue does not seem to happen in my localhost.

First, I try to inspect the element. At first I could not find anything since all Mui- classnames are renamed to jss1, jss2, etc. Thus, I have to do my own mapping to map the class to my code. Then, when I inspect the styles, it seems like CSS classnames jss1 overrides each other.

I managed to solve the problem by:

1. Remove material-ui, @material-ui/icons, and @material-ui/core (it is because the @material-ui/icons are already referencing to @material-ui/core)
2. Add back @material-ui/icons and material-ui (the beta version)

Voila!! It works!! Yay!!

Github API v4

After that, I try to fetch data from the github API v4. Since some Mozilla project has more than one repositories, I want to find query format that can gather all bugs from several repositories. At first, I don’t think it is provided, thus, I use something like the below, with a little modification to add labels as parameter, a few more fields that I need, and ordering:

{
 a: repository(owner:"mozilla", name:"coversheet"){...OpenIssues }
 b: repository(owner:"mozilla", name:"memchaser"){ ...OpenIssues }
}
fragment OpenIssues on Repository{
 nameWithOwner
 issues(first: 100, states: [OPEN]){
  nodes{
   number
  }
 }
}

However, though it works fine, I feel like it is not very efficient, since we have to do a lot of processing, before and after the query.

Later on, my mentor, Eli, suggested me to try on using search query which I think I will end up using as it reduces the processing needed since we can specify all we want in a single string and pass it as parameter.

However, a little shortage is that the query string works like AND operation for labels. Thus, when we have different labels for different repositories, we still need to separate the query to find bugs which only satisfy one label (good-first-bug only instead of good-first-bug and mentored). I hope one day the Github GraphQL team can provide some way to do OR operation in the labels.

I also fix some styling, remove redundant classes and delete some redundancies based on the review from Hassan, my other mentor. I also try to play with the Bugzilla GraphQL gateway to find out the query I will need. Lastly, I had a video chat with Abigail from Mozilla Foundation, after getting introduced to her by Dustin, to talk about how the work I do can be integrated with other pieces in Mozilla. I made a few notes about the chat and discussed it with my mentors. I believe talking to more people gives me a different view of how this project should progress and I really appreciate her taking her valuable time to listen to me and giving her suggestions.

My second week as Outreachy Intern

Hi guys! This is my second week as Outreachy Intern. Since I usually write posts on Tuesday, I guess these weekly posts shall be about what I have done in the last week and my plan for this week.

Last week, I start utilizing Github Project Board to track my progress, current issue, as well as future plan for the projects. After about a week of utilizing it, I feel like it is quite useful to remind me of what I should be doing next, but I think I should have created smaller (more detailed) bugs instead of a bug having lots of changes. I think it will make it easier for the reviewer to review

Last week, I initialized the projects, add README, create a homepage which contains the projects list and brief information in the form of a card, and create an individual project page. The picture of the UI is shown below. I haven’t added much styling, it is still in B/W default value from MaterialUI.

Some challenges I face during last week are planning the projects, changing the plan, and re-planing. Regardless, I am very thankful to have my mentors’ opinions, suggestions, and reviews along the way.

This is the homepage

This is the individual project page

This week I will try to look into how I should fetch information using Github Graphql API as well as Bugzilla, if time permits. There are also minor things which I think this site should have and I plan to add those into the Project Board.

I really hope this project will turn out to be useful by many, thus, feel free to give me inputs, add an issue (as done here), and join the mailing list.