dev.to에서 발표할 수 있는 가장 좋은 시간은 무엇입니까?데이터 지원 답변🕰🦄🤷‍♂️

19370 단어 beginnersmetawebdevpython
dev.to는 몇 년 전에 출현한 훌륭한 블로그 플랫폼이다.나는 그것을 위해 그곳에서 출판된 내용을 쓰고 읽는 것을 좋아한다.하지만 내가 가장 좋아하는 것은 모든 사람들이 이 플랫폼에 세워진 지역사회라고 생각한다.
모두가 알다시피 한 지역사회는 서로 다른 유형의 취미와 평론을 통해 포스터와 대량의 상호작용을 한다.dev.to에는'인과응보'가 없지만 한 편의 게시물의 인기 정도를 평가하는 방법은 해당 게시물과 커뮤니티의 상호작용 횟수를 보는 것이다.
댓글의 수량, 물론 좋아하는 수량도 있습니다. 플랫폼에서 세 가지로 나뉘는데 그것이 바로 딱정벌레입니다.🦄, 마치... 와 같다❤ 및 책갈피📕.
나는 최근에 하루 어느 시간에 발표한 문장이 다른 문장보다 더 잘 표현되었는지 알고 싶다.그렇다면 가능한 한 많은 사람들이 읽을 수 있도록 블로그 글을 발표하는 가장 좋은 시기는 무엇일까.나는 약간의 직감이 있지만, 나는 증거와 사실을 가지고 처리하고 싶다.
다음은 내가 한 일이다.

데이터 수집:
나는 앞으로 이런 데이터를 어떻게 효과적으로 수집하는지 상세하게 설명하기 위해 긴 댓글을 한 편 쓸 것이다.
나는 최근dom에서 모든 문장에 사용할 수 있는 공공 id가 있다는 것을 알아차렸다.

또한 다음과 같은 사용자 정보를 얻을 수 있는 공통 단점도 알고 있습니다.
http https://dev.to/api/users/<user_id>
그래서 자연스럽게 저도 같은 방법으로 이 글을 써 보려고 합니다...
http https://dev.to/api/articles/81371
HTTP/1.1 200 OK
{
    "body_html": "<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\">\n<html><body>\n<p>The other day I was touching up a PR that had been approved and was about to merge and deploy it when, out of habit, I checked the clock. It was 3:45pm, which for me, was past my \"merge before\" time of 3:30pm. I decided to hold off and wait until the next morning. </p>\n\n<p>The whole process got me thinking. Does anyone else have their own personal merge or deploy policies? Is there a time before or after when you say, not today? Is there a day of the week you don't like to merge stuff. A lot of people joke about read-only Fridays, but I have to admit, I kinda follow that rule. Anything remotely high risk I wait until Monday to merge. </p>\n\n<p>What's your personal merge/deploy policy?</p>\n\n</body></html>\n",
    "canonical_url": "https://dev.to/molly_struve/whats-your-personal-mergedeploy-policy-30mi",
    "comments_count": 6,
    "cover_image": "https://res.cloudinary.com/practicaldev/image/fetch/s--o6RV_02d--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/oqg9vv4u2c5orc3y2n6n.png",
    "description": "What's your personal merge/deploy policy?",
    "id": 81371,
    "ltag_script": [],
    "ltag_style": [],
    "path": "/molly_struve/whats-your-personal-mergedeploy-policy-30mi",
    "positive_reactions_count": 13,
    "published_at": "2019-03-22T22:19:36.651Z",
    "readable_publish_date": "Mar 22",
    "slug": "whats-your-personal-mergedeploy-policy-30mi",
    "social_image": "https://res.cloudinary.com/practicaldev/image/fetch/s--MJYBx9D---/c_imagga_scale,f_auto,fl_progressive,h_500,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/oqg9vv4u2c5orc3y2n6n.png",
    "tag_list": "discuss",
    "title": "What's your personal merge/deploy policy?",
    "type_of": "article",
    "url": "https://dev.to/molly_struve/whats-your-personal-mergedeploy-policy-30mi",
    "user": {
        "github_username": "mstruve",
        "name": "Molly Struve",
        "profile_image": "https://res.cloudinary.com/practicaldev/image/fetch/s--UrIkLrxe--/c_fill,f_auto,fl_progressive,h_640,q_auto,w_640/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/119473/9e74ee0e-f472-4c33-bfb4-79937e51f766.jpg",
        "profile_image_90": "https://res.cloudinary.com/practicaldev/image/fetch/s--apWeHy1C--/c_fill,f_auto,fl_progressive,h_90,q_auto,w_90/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/119473/9e74ee0e-f472-4c33-bfb4-79937e51f766.jpg",
        "twitter_username": "molly_struve",
        "username": "molly_struve",
        "website_url": "https://www.mollystruve.com"
    }
}
그리고 빙고!!
내가 지금 해야 할 일은 첫째, 문장의 id가 순서대로 배열되었는지, 둘째, 만약 1이 사실이라면, 최근의 문장의 id를 찾는 것이다.
이 두 가지 일은 모두 검사하기 쉽다.나는 단지 최근의 문장에서 브라우저 검사기를 몇 번 열었을 뿐이다.
다음에, 나는scrasty를 사용하여 이 API 94k를 호출하고, 정보를 뚜렷한 저장소에 저장한다. .csv이 방면에 대한 더 많은 정보는 미래의 게시물에 발표될 것이다.
이를 위해 ScrapingBee를 사용했습니다. 이것은 제가 최근에 내놓은 제품입니다web scraping tool.😎.

우리 지금 뭐 있지?
94k API 호출 중 거의 절반이 a404: resource not found로 반환되었습니다.나는 이것이 절반의 문장이 지금까지 발표된 적이 없다는 것을 의미한다고 추측하지만, 나는 확실하지 않다.나는 여전히 약 4만 개의 데이터 포인트를 가지고 있는데, 이것은 나의 관점을 증명하기에 충분하다.
내 csv의 줄마다 여러 가지 유용한 정보가 있지만, 내가 찾고 있는 내용에 대해서는 숫자나 유사물, 발표 날짜 두 가지가 필요하다.
API가 이 두 가지를 되돌려 주기를 바랍니다. 이전 단락의 positive_reaction_count 과 published_at 을 참고하십시오.

풍부한 데이터
데이터를 처리하기 위해서, 나는 모두가 알고 있는python 라이브러리, 심지어는 the most famous python package on GitHub 중의 하나를 사용했다.
나는 여기에서 코드 세션을 보여줄 것이다. 만약 당신이 더욱 전면적인 강좌를 원한다면, 평론에서 나에게 알려주십시오.
pandas를 사용하여 csv에서 데이터를 로드하는 것은 매우 간단합니다.
import pandas as pd
df = pd.read_csv('./output.csv')
dev.to에서 발표할 가장 좋은 시간/날짜를 알고 싶어서 published_at열을 다른 두 열로 바꿔야 합니다. day_of_week('Mon','Tue',...)및 hour.
판다는 데이터를 쉽게 추가하고 변환하며 조작할 수 있습니다.내가 해야 할 일은 바로 그 몇 줄이다.

df['hour'] = pd.to_datetime(df['published_at']).dt.hour

days_arr = ["Mon","Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]

def get_day_of_week(x):
    date = pd.to_datetime(x)
    return days_arr[date.weekday()]

df['day_of_week'] = df['published_at'].apply(get_day_of_week)
나의 모든 데이터는 현재 하나의 데이터 상자에 저장되어 있다. 나의 판다가 사용하는 주요 데이터 구조이기 때문에 이름을 얻었다. df.

약간의 데이터, 즉
나는 지금 내가 필요로 하는 모든 정보를 가지고 있다.
다음은 내 데이터 상자의 내용입니다.
일주일 중 이튿날
시간
양성 반응 계수
청화대학
0
4
월, 월요일
1
34
...
...
 ...
태양.
22
41
청화대학
17
9
한 줄마다 한 개의 댓글을 대표하는데, 나는 약 38k줄을 가지고 있다.
이어서 나는 자연스럽게 하루 한 시간의 총결산을 했다positive_reaction_count.
다음은 판다에게 어떻게 이 점을 할 수 있는지.

aggregated_df = df.groupby(['day_of_week', 'hour'])['positive_reaction_count'].sum()
현재 나의 df는 이렇게 보인다.
낮.
시간
양성 반응 계수
월요일
0
4110
1
3423
2
2791
...
...
 ...
22
4839
23
3614
...
...
 ...
일요일 명사
0
110
1
423
2
731
...
...
 ...
22
4123
23
2791
다행이다. 내가 필요로 하는 형식의 데이터를 얻기 위해서는 일이 좀 더 필요하다.
기본적으로 회전 기둥이다.

pivoted_df = aggregated_df.reset_index().pivot('hour', 'day_of_week', 'positive_reaction_count')
현재 나의 df는 이런 외관을 가지고 있다.
시간
월, 월요일
화요일.
...
태양.
0
4110
5071
...
5208
1
3423
4336
...
3230
2
2791
3056
...
1882
...
...
...
...
...
23
3614
4574
...
3149
이제 나는 마침내 seaborn 패키지로 아름다운 히트맵을 표시할 수 있게 되었다.
import seaborn as sns
sns.heatmap(pivoted_sorted , cmap="coolwarm")
다음은 내가 얻은 것이다.


분석하다.
나는 이 열도가 매우 간단해서 말하지 않아도 자명하다고 생각한다.지도상에서 두 지역이 눈에 띈다.빨간색, 왼쪽 아래, 짙은 파란색, 오른쪽 위.
그러나 우선, 우리가 이야기하는 것은 시간이기 때문에, 우리가 이야기하는 것이 어떤 시간대인지 알아야 한다.
자세히 published_at": "2019-03-22T22:19:36.651Z 보면 시간 문자열의 끝에 Z 가 있음을 알 수 있습니다.
이것Z은 이 시간 문자열이 UTC 시간 또는 시간대Z를 나타냅니다.
그래서 우리의 뜨거운 그림으로 돌아가면 월요일부터 수요일 오후(동해안의 사람들은 월요일과 수요일 오전)가 지도상에서 비교적 활발한 지역이라는 것을 알 수 있다.
토요일과 일요일은 매우 평온한 날이다. 특히 자정부터 정오까지.
그래서 여기서 언뜻 보면 이 시간을 붙여서 좋아하는 기회를 최대한 늘리는 것이 좋다고 생각할 수 있다.우리는 한 걸음 물러나야 한다.
이 뜨거운 그림은 하루 중 우리가 가장 좋아하는 시간을 관찰하는 것을 보여 준다.그것은 더 많은 댓글이 자동으로 더 많은 사랑을 의미한다는 사실을 고려하지 않았다.
그래서 아마도 지금 우리는 아직 확실하지 않다. 우리가 열도에서 본 빨간색 구역은 단지 우리가 플랫폼에서 관찰하는 것 같다는 것을 의미할 뿐이다. 단지 이 기간에 더 많은 글이 발표되었기 때문이다.
이러한 차이는 우리가 알고 싶은 것은 우리의 취향을 최대한 넓히기 위한 가장 좋은 시기이기 때문에 이 지도는 우리에게 도움이 되지 않는다.
그래서 우리는 똑같은 지도를 만들어야 하지만 매일 한 시간 동안 좋아하는 총수를 계산하는 것이 아니라 좋아하는 평균수를 계산하는 것이다.
우리도 중위수를 계산할 수 있다. 나는 해냈다. 큰 차이가 없다🙂.
판다 덕분에 우리는 코드의 작은 일 하나만 바꾸면 된다.

# sum -> mean
aggregated_df = df.groupby(['day_of_week', 'hour'])['positive_reaction_count'].mean()
다음은 새로운 히트맵입니다.

보시다시피 열도는 앞의 그림과 매우 다르고 앞의 그림보다 이용하기 쉽다.
우리는 지금 줄무늬 도안을 관찰하고 있다.이 파란색 와이드 버전은 월요일부터 일요일까지 아침 4시부터 10시까지입니다.
또한 UTC의 오후 활동 정점도 살펴봤습니다.
이 핫픽처 뒤에 저희가 지금 얘기할 수 있어요.
오후 게시된 글은 UTC일보다 평균 일찍 게시된 글보다 10∼20회 긍정적으로 상호작용했다.
나는 이것이 모두 독자/작가 비율과 관련이 있다고 생각한다. 이 두 장의 열도는 주말에 독자 수가 훨씬 적지만 작가 수도 그만큼 줄어든다는 것을 보여준다.주말에 발표한 글과 일주일에 발표한 글의 상호작용 횟수가 같은 이유다.

읽어주셔서 감사합니다.
나는 네가 이 댓글을 좋아하길 바란다.
이 시리즈는 아직 끝나지 않았습니다. 이 데이터 집합과 관련된 더 많은 정보를 보여 드리겠습니다.
평론에서 저에게 개발의 어떤 측면에 대해 데이터 분석을 하고 싶다면 subscribe 저의 시사통신을 읽고 더 많은 내용을 읽는 것을 잊지 마세요(다음 전자책의 제1장을 무료로 받을 수 있습니다)😎).
만약python 기교를 계속 읽고 싶다면, 가라. 너는 그것을 좋아할 수 있다.
만약 네가 JS를 좋아한다면, 나는 이미 발표할 것이다.
니가 git를 더 좋아하면
NGINX 타이머
HDU 2177 첫 번 째 방법

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
best100-homepage