teleren/devto huggingface dataset:
JavaScript Filter
Tags: javascript, webdev, beginners, programming
Published: 2021-11-20 05:09:33

* [Definition](#def)
* [Filter Tips](#tips)
* [Conclusion](#conclusion)

<a id="def"></a>
#Definition

The `filter()` method returns new array with all the elements that pass the test implemented by provided function.

<a id="tips"></a>
#Filter Tips
Check below code for filter.
```javascript
If you have array like this.

const data=[
  {name:"prakash",age:20},
  {name:"bhanu",age:21},
  {name:"mohan",age:40}
];

// Then instead of writing code like this 
const select_user=data.filter(function(user){
    if (user.name==="prakash"){
       return true
    }
    return false
});
```

You can simplify code as shown it below:

```javascript

let selected_user=data.filter(function(user) {
    return user.name==="prakash"
})

```

The above code will return true,if the condition is satisfied otherwise it will return false

We can simplify above code much more simple and understandable using `ES6` syntax.

```javascript

let selected_user=data.filter((user)=> user.name==="prakash")

```

<a id="conclusion"></a>
#Conclusion

1. Filter method returns a new array consisting only those 
   elements that satisfied the provided function.

2. Filter method does not change original array.

3. Filter method does not execute function for empty elements.


I hope You will learn something from this post.If there are more usecases, please mention in below comment section.

Thanks.
DPS909 - Release 0.3 Code Reviews
Published: 2021-11-20 05:01:47


# Introduction
For the last part of the Release 0.3 assignment for DPS909, we had to review two pull requests from the **internal** repositories. This included [Telescope](https://github.com/Seneca-CDOT/telescope) and [IPC144](https://github.com/Seneca-ICTOER/IPC144).

## Code Review 1
The first code review was in the IPC144 repository. Here is the link to my [review](https://github.com/Seneca-ICTOER/IPC144/pull/83#pullrequestreview-808808812). Overall the submitted markdown file was very well audited, however, I did notice that there were some code blocks that were not utilizing any type of syntax highlighting, so I reviewed the PR and commented that there should be a possibility of using the `c` syntax within those two specific code blocks. 

## Code Review 2
The second code review was also in the IPC144 repository. Here is the link to my [review](https://github.com/Seneca-ICTOER/IPC144/pull/84#pullrequestreview-808833883). I audited the entire pull request file called `More Input and Output.md`, and noticed that the author did a great job with their audit. I let them know that I reviewed everything and that it all checked out. I left a comment and approved the pull request. 

# Conclusion
Overall, I really liked this part of the assignment as it let me review and check other students code, and gave me some real world experience with reviewing pull requests. The process of reviewing a pull request is very important, as it ensures that only the highest quality code gets pushed into the `main` branch.
DPS909 - Release 0.3 Internal Pull Request
Published: 2021-11-20 04:50:36

# Introduction
For release 0.3 in DPS909, we had a few parts that we needed to accomplish in the assignment. This blog post will discuss my experience with contributing to an **internal** repository. The repository of choice was [IPC144](https://github.com/Seneca-ICTOER/IPC144).

To find out what exactly the IPC144 repository is, click [this](https://github.com/Seneca-ICTOER/IPC144) link.

## The issue
The issue that was brought up in this **internal** repository, was to 
audit the `style-guidelines.md` file. There is a very specific checklist that we had to abide by, to ensure that our audit was done correctly.
Here is the link to the issue: [ISSUE-49](https://github.com/Seneca-ICTOER/IPC144/issues/49)

## The PR
So, I began my journey of auditing `style-guidelines.md`.
### Setup
The setup for the IPC144 was super straight forward. It utilizes [Docusaurus](https://docusaurus.io/). I followed the steps in the [Contributing](https://github.com/Seneca-ICTOER/IPC144/blob/main/CONTRIBUTING.md) file, and was able to get it up and running quickly. By doing so, I was able to get quick reload, meaning that any changes that I would make, would be instantly reflected on the localhost.

### The Audit
The audit was rather simple. I followed each item in the checklist, and would go through and ensure that the selected item was done correctly. This included items such as checking for typos, ensuring the Markdown elements are converted correctly, using code blocks for syntax highlighting, etc. 

Here you can find my PR: 
https://github.com/Seneca-ICTOER/IPC144/pull/92

## The Conclusion
Overall, this **internal** issue was simple, however, it introduced me into the world of auditing pages to ensure that they are done to the highest quality. Following the checklist made my journey a ton easier, and in the end I had a high quality markdown file.
Octo: Continuous Integration
Tags: javascript, webdev, opensource, tutorial
Published: 2021-11-20 04:49:06

Welcome to another post about my project [Octo](https://github.com/LuigiZaccagnini/octo)! In this blog I am going to go over:

- The process of integrating CI(continuous integration) into my open source project Octo
- How writing tests for another repository felt
- Thoughts of CI

## Continuous Integration
Setting up CI with Github actions was extremely easy. Github has prefabs of node configurations making CI easy to integrate in your project. If you followed my previous blogs about [testing](https://dev.to/luigizaccagnini/creating-tests-for-octo-2okg) and [static analysis tooling](https://dev.to/luigizaccagnini/using-static-analysis-tooling-with-open-source-67n), creating your config should be short. 

1. Navigate to your Github repository and click the actions button beside projects.

2. Click on the basic node configuration. Once you click on that, it should bring you to a new page with the creation of a .yml file.  

```
name: Node.js CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"
      - run: npm ci
      - run: npm run prettier-check
      - run: npm run eslint
      - run: npm test
```

Octo's .yml looks like the above code. Most of the code above was provided by Github as a template to start with. I only added my npm commands created before as checks for the CI so, if you haven't done that yet you should go read those blogs! Once this is done, your CI should be now included in your repository! 

## Writing Tests in Another Repo
Working in another person's repo was a little tough. The repo's contributing.md was outdated so I had to find the files and commands to use for testing the project. Once I was able to figure that out writing a new test was not as difficult because of Jest's `--coverage` flag. This helped generate a report to find all the missing coverage for tests in the project. This also helped me understand how the project works and how to write tests for it.

## Final Thoughts on CI
I think everyone should have CI integrated in their projects, even if it is being developed solo. I believe this is important for each project because it helps keep broken code from being pushed to a repo. Although developers may feel that they won't run into this, keeping a mind set of writing tests while developing a project makes your code better.
3 - 100 DaysOfCode
Tags: 100daysofcode, design, planning, github
Published: 2021-11-20 04:48:32

19NOV2021

Today I was **planning** part of the initial design work and created a project in the git repository, which is very good as a **collaboration tool** with other members.

[Design project](https://github.com/shift-dominicana/WaltCommerce/projects/2)
Here you can document your work, do sprints or milestones, and check your progress against a deadline.
In this design project I'm **planning to include** task related to Mockups, UI/UX, Flow diagrams, data diagrams and those stuff.
Reviewing PRs in Telescope
Published: 2021-11-20 04:42:02

Reviewing PRs in Telescope has been really interesting. I know I discussed earlier about my work with the Avatars in the GitHub information section, and I found a [PR](https://github.com/Seneca-CDOT/telescope/pull/2447) that built on the implementation for that. 

For this PR, I took the time to build the application on my end locally. I additionally tried to play around and see if it would break anything (scrolling, lightmode/darkmode etc). To my surprise everything was great - and therefore was a simple approval!

The second [PR](https://github.com/Seneca-CDOT/telescope/pull/2500) I reviewed was also interesting, but required a more complicated solution. Something which I also was not too familiar with. Again, I took the time to build the application locally and play around with it. I then opened up the web and navigated to the Telescope website to see the changes. I honestly had a hard time with the color scheme for the code blocks in dark mode. Knowing myself well, I have difficulty reading on screens anyways, and had seen the repository owner had provided suggestions to stylesheets to use, and the contributor had used one of those, so I decided this was sufficient enough. After testing in light/dark mode I noticed the code blocks were changed in the lightmode too - something I was not too sure was correct. I wrote a comment about this, and the contributor was quick to respond that they were trying to find a solution for this - hence it was a draft PR. I was intrigued. I could provide a solution for this in Angular so easily, but being this was React, I went to the web to search how this could possibly be implemented - to provide some help. After providing some suggestions, the repository owner had made a suggestion to the correct approach, noting my approach would not work. 

Although my review was not very helpful, I believe by contributing and exploring different issues, we always learn something. For example, eventually we did get a better suggestion on the PR. Sometimes, the easier way to learn something is through reviewing.
DPS909 - Release 0.3 External Pull Request
Published: 2021-11-20 04:40:12

# Introduction
For release 0.3 in DPS909, we had a few parts that we needed to accomplish in the assignment. This blog post will discuss my experience with contributing to an **external** repository. The repository of choice was [Meshery](https://github.com/meshery/meshery.io).

To find out what exactly Meshery is, click [this](https://github.com/meshery/meshery.io#what-is-meshery) link.

## The issue
The issue that was brought up in this **external** repository, was to create a Legend, that resembled a Legend from a different page within the Meshery codebase.

Here is the link to the issue: [ISSUE-616](https://github.com/meshery/meshery.io/issues/616)

## The PR
So, I began my journey of implementing the legend on that specific page.
### Setup
The setup was rather easy, however with being a ruby based application, it did not really like Windows. The instructions found in Mesherys README helped streamline the process for me, however I did have to iron out some kinks. There were two gems that needed to be installed manually (tzinfo and tzinfo-data). Once those two gems were installed all I had to do was execute 

```bundle exec jekyll serve --drafts --livereload```

### Implementation
Finding where I needed to implement my changes did not take long to find. Once I saw the general structure of the code, I quickly began modifying the HTML elements and the CSS styling. The HTML elements were very quick to create, however the CSS styling took majority of my time. I do not have the most CSS experience, so I was glad I took on this challenge. The hardest part was figuring out the flex-boxes, and their positioning on the screen, as well as ensuring that with a Mobile view, everything still looked correct and in order. To make my Legend look good, I downloaded the same icons that can be found [here](https://meshery.io/service-mesh-interface), and used them in my legend. Doing so would make the user understand the icons better, as well as their meaning.

Here you can find my PR: https://github.com/meshery/meshery.io/pull/617

## The Conclusion
Overall, I found working on this external issue really rewarding. Not only did it challenge me to get the CSS working accordingly, but it felt really rewarding once I saw it being responsive, and behaving as expected. I also found the contributors of Meshery to super nice and quick to respond to PR comments.
Mitigating MySQL Downtime for big migrations
Tags: mysql, migrations, devops, performance
Published: 2021-11-20 04:36:14



I have been using MySQL for the last 3 years. In the beginning, the data size was small and manageable.

The problem started occurring when one of our tables grew to a size of 15 GB.

But 15 GB is nothing for MySQL, right? That’s what we thought.

Digging deeper we found that our index size was also 15GB. This can be solved if keep on increasing the database systems’ size and upgrade it.

To remove indexes, MySQL has `drop index` available with multiple options like

```
algorithm_option:
    ALGORITHM [=] {DEFAULT | INPLACE | COPY}

lock_option:
    LOCK [=] {DEFAULT | NONE | SHARED | EXCLUSIVE}
```
There are still things we need to consider before running this, like what will happen if the table is heavily used and updated very frequently.
To avoid that we can do the following things
1. Create New table
2. Copy data to the new table
3. Create procedures for inserts/updates in the original table
4. Drop index ( or any heavy operation, like optimize table )
5. Rename the table back to original
6. Drop old table
7. Drop procedures

Those are a lot of things. Wish we had a tool for this, so we could just automate it.

**Percona Toolkit by Percona**

More specifically for this change, we need pt-online-schema-change [https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html](https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html)
With this tool, any operation related to the schema can be done in the background.
```
pt-online-schema-change --alter="ADD INDEX big_table_name (some_column_name)" \ 
--analyze-before-swap --recursion-method=none D=db_name,t=big_table_name,h=hostname,\
u=user_name --ask-pass --preserve-triggers --execute
```

Above is a simple add index operation. Even if the table is big, in the options we can specify how much CPU should be maintained. How many resources could be consumed by this utility.

What if you had replicas, and the lag becomes higher than usual. We can skip checks for them to avoid interruption.
List of options which can be passed are available here 
[https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html#options](https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html#options)
code every day with me
Tags: javascript, programming, 100daysofcode, algorithms
Published: 2021-11-20 04:06:17

##--DAY 24--
Hi, I am going to make #100DaysOfCode Challenge. Everyday I will try solve 1 problem from leetcode or hackerrank. Hope you can go with me until end.
**Now let's solve problem today:**
- Problem: Happy Number
- Detail: [here](https://leetcode.com/problems/happy-number/)
- Idea: After each step we split number, store new number to array, to check if number loops endlessly in a cycle, we need to check if array has any number appears twice or not. 
   - Example: 2
   - step1: 2^2 = 4; array = [4];
   - step2: 4^2 = 16; array = [4,16];
   - step3: 1^2 + 6^2 = 37; array = [4,16,37];
   - step4: 3^2 + 7^2 = 58; array = [4,16,37,58];
   - step5: 5^2 + 8^2 = 89; array = [4,16,37,58,89];
   - step6: 8^2 + 9^2 = 145; array = [4,16,37,58,89,145];
   - step7: 1^2 + 4^2 + 5^2 = 42; array = [4,16,37,58,89,145,42];
   - step8: 4^2 + 2^2 = 20; array = [4,16,37,58,89,145,42,20];
   - step9: 2^2 + 0^2 = 4; array = [4,...,4];
   - Because number 4 appears twice, we return false. 
- My solution(javascript):
```js
var Sum=(n)=>{
    let tmp=0;
    while(n>0){
        tmp=tmp+(n%10)**2;
        n=parseInt(n/10);
    }
    return tmp;
}
var isHappy = function(n) {
    let ans=[],i=1;
    ans[0]=n;
    while(i){
        let nums = Sum(ans[i-1]);
        if(nums==1) return true;
        else if(ans.includes(nums)) return false;
        ans.push(nums);
        i++;
    }
};
```
-->*If you have better solution or any question, please comment below. I will appreciate.*
Ruay เว็บที่ได้รับความนิยมเป็นอย่างมาก
Published: 2021-11-20 04:03:01

เว็บไซต์ให้บริการซื้อหวยออนไลน์ระดับต้นๆของประเทศอย่าง Ruay ที่เปิดให้บริการมาอย่างยาวนาน ทีมีทั้งหวยในประเทศและหวยนอกประเทศให้เลือกแทงเป็นจำนวนมาก มีความมั่งคงปราศจากการโกง อัตราการจ่ายที่สูงถึบาทละ 900 มาพร้อมกับระบบ ฝาก-ถอน อัตโนมัติที่สะดวกรวดเร็วจึงทำให้ RUAY เป็นเว็บที่ได้รับความนิยมอยู่ในเวลานี้ ท่านใดกำลังหาเว็บเล่นอยู่ไม่ควรพลาดอย่างยิ่ง

https://ruaygod.com/
How I Reviewed Code for Seneca-ICTOER
Published: 2021-11-20 04:00:18

As I was working on the modernized version of [IPC144](https://github.com/Seneca-ICTOER/IPC144/), there were many pending pull requests (PR) made by other students. I decided to help them out with reviewing their pull requests. Most of them were well done, so I could only give a few recommendations to some of them. Here are two of them.

## Reviewed PR for `Informataion.md`

In the [PR](https://github.com/Seneca-ICTOER/IPC144/pull/81), I noticed the author accidentally committed two irrelevant files: `https-webhint-io.html` and `yarn.lock`. He was supposed to modify only a Markdown file, but he probably added his [Web Hint](https://webhint.io/)'s report by mistake. I made a comment on it, which helped him eventually remove those irrelevant files from his PR.

## Reviewed PR for `More Input and Output.md`

After reviewing the [PR](https://github.com/Seneca-ICTOER/IPC144/pull/84), I noticed a tiny whitespace character that could lead to misunderstanding. The original text was:

> `"%*c%c"` discards/ignores **one** character and accepts the next.
`" %c"` discards/ignores **all** whitespace characters before the next non-whitespace character.

The whitespace in `" %c"` was then removed by the author. However, this whitespace character was actually necessary for the expression to discard/ignore all whitespace characters.

## Final thoughts
Code review surely requires attention to details, but it can be done more easily with collaboration. I really appreciate others' effort on reviewing my PR and suggesting interesting areas of improvement. I hope that I have a chance to review more challenging work next time.

---
PR #1: https://github.com/Seneca-ICTOER/IPC144/pull/81
PR #2: https://github.com/Seneca-ICTOER/IPC144/pull/84
How I Contributed to an OER Project
Tags: opensource
Published: 2021-11-20 04:00:06

I finally had a chance to work on [IPC144](https://github.com/Seneca-ICTOER/IPC144), an Open Educational Resources (OER) project with a view to modernizing the old [IPC144 course website](https://ict.senecacollege.ca/~ipc144/) with [Docusaurus](https://docusaurus.io/). As a first time contributor, I found a perfect issue to get familiar with the project: auditing and fixing the automatically translated Markdown files.

## Getting started
As instructed in the [meta issue](https://github.com/Seneca-ICTOER/IPC144/issues/18), I opened a new [issue](https://github.com/Seneca-ICTOER/IPC144/issues/28) for the page on which I'd like to work. Once I'd cloned the repository, I could immediately start auditing the Markdown file without any additional configuration. I had to go over a long checklist posted in the meta issue, but I'll discuss what I've found interesting in this blog.

## Docusaurus Features
Docusaurus has 2 distinct features that can significantly improve the old IPC144 website:

- Frontmatter: the top section of a content file used for specifying metadata and Docusaurus's configuration variables
- Admonition: a highlighted section in a content file

### Frontmatter
![Frontmatter example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1qfuec97yu37tjna7ja3.jpg)
 
Docusaurus supports a large number of [Frontmatter fields](https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-docs#markdown-frontmatter). I added 4 of them to the Markdown file for SEO optimization:

```
---
id: algorithms
...
title: Algorithms
slug: /refinements/algorithms
description: An algorithm is the set of rules that define the sequence of operations required to complete the task.
---
```

### Admonition
There were some noteworthy sections of the page. However, they barely stood out because of the use of Markdown blockquote like this:

![Blockquote](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dvvf597a7lqa04njn20m.jpg)

Luckily, Docusaurus' [Admonition](https://docusaurus.io/docs/markdown-features/admonitions) is perfect for this role. It is really eye-catching and easy to use. For example, I can enclose the content with `:::note` and `:::`:

```
:::note

The value returned by `find()` (variable `i`) is validated to ensure that it is within the bounds of the key array (that is, we check that it is not -1 and not more than the number of items in the array). 

:::
```

and it will be rendered like this:

![Admonition Example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lo39l1hhnh2tv2oykec7.jpg)

## Final thoughts
Although it might seem like a small issue, it's still very satisfying to know that [my contribution](https://github.com/Seneca-ICTOER/IPC144/pull/72) can enhance the learning experience of other fellow students.

---
Issue: https://github.com/Seneca-ICTOER/IPC144/issues/28
PR: https://github.com/Seneca-ICTOER/IPC144/pull/72
Docusaurus: https://docusaurus.io/docs
Reviewing PRs
Tags: opensource, javascript, markdown
Published: 2021-11-20 03:59:46

Our final task for release 0.3 was to review two PRs made by our peers. The two PRs that I reviewed were from the IPC144 repo, just like the PR I made. I helped do reviews of PRs that were also auditing and fixing markdown files. You can check them out [here](https://github.com/Seneca-ICTOER/IPC144/pull/84) and [here](https://github.com/Seneca-ICTOER/IPC144/pull/100).

The process I took was slightly different from what I did for my own pull request. First I took a look at the changes that they made in their PR. I would check every line that was modified and run that against the checklist to make sure that it matched the changes needed. Then I would just read through them normally as well to just check for any human error. Afterwards, I copied their updated markdown and tested it locally on my own machine to do my own audit of their audited version to see if I could spot any issues. I checked both the raw markdown file and the website version just like my own PR. Then I ran it through Lighthouse and Web Hint to check for any issues. Finally double check for any issues with light/dark mode and the mobile version of the webpage.

Both of the PRs I reviewed were very well done and thorough, they had very minimal errors to them and I was really only able to be nitpicky with one spacing mistake. It was interesting to see how different people approach the different changes such as alt text for images. While there is a best way to describe an image I was having some trouble naming some of the diagrams in my own PR but seeing how other people approached it allowed me to learn from their methods. As I stated in my previous blog post, this is really the power of open source allowing us to pool together our collective knowledge and methodologies, in turn making each other smarter and better. Anyways that's all for now, so until next time take care!