@one_programmer

لیستی از بهترین الگوریتم ها و ساختارهای داده در #C

https://github.com/abdonkov/DSA

@one_programmer

@one_programmer

فردا ۲۲ شهریور، روز ۱۱۱۱۱۱۱۱ سال در زبان ماشین (کد باینری / دستگاه اعداد دودویی) است که می‌شود ۲۵۶مین روز سال (در سال‌های کببیسه هم با فرض اینکه اولین روز سال، روز صفرم سال باشد [شمارش در خیلی از زبان‌های برنامه‌نویسی از صفر می‌شود] می‌شود ۲۵۶مین روز سال!). این روز به عنوان روز برنامه‌نویس‌ها نامگذاری شده چون شاید از چیزهایی که گفتم غیر از برنامه‌نویس‌ها کسی چیز زیادی متوجه نشود!

برنامه‌نویس‌ها می‌توانند خوشبخت‌ترین آدم‌های روی زمین باشند چون کاری که ازش لذت می‌برند (خلق کردن مفهومی انتزاعی که خیلی‌ها از آن چیزی نمی‌فهمند اما کارهایی انجام می‌دهد که انسان از انجام آن ناتوان است) را انجام می‌دهند و در قبال آن پول هم می‌گیرند!

برنامه‌نویس‌ها روزتون مبارک!
@one_programmer

@one_programmer

وقتی از وب کم استفاده میکنی :)
@one_programmer

@one_programmer
به مناسبت روز برنامه نویس :)
روزتون مبارک

@one_programmer

@one_programmer
وضعیت برنامه نویسا :)

@one_programmer

@one_programmer
.Net Core C# vs PHP7 #مقایسه

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=php

منبع: IranAspMvc
@one_programmer

@one_programmer
بعد دیدن این بنچمارک یاد قدیم افتادم.
یادمه زمانی که php کار میکردم، تازه نسخه 7 PHP اومده بود. ما خیلی خوشحال بودیم بابت چند تا چیز:
اولیش این بود که
1- این ورژن ۷ تو سرعت اجرا رسیده بود به HHVM ی که فیسبوک برای خودش توسعه داد بود چون php جوابش رو نمیتونست تو این حجم کار بده، و ورژن ۷ از HHVM فیسبوک‌کمی سریعتر بود که میشه گفت فضایی بود
2- اینکه یه سری کارای ساده که تقریبا هر زبانی داره، تازه تو ورژن ۷ اضافه شده بود به php
و یه سری اتفاق دیگه
گرچه هنوزم multi thread کد زدن با php آرزوست، در حالی که خیلی زبان ها اینو سالیانه حل کردن :)
مقایسه بالا رو برید بخونید، Net core. که قبلا در موردش بحث کردیم از لحاظ زمان اجرا در اکثر مواقع حتی بیشتر از ۱۰ برابر سریعتر هست.
@one_programmer

@one_programmer

تفاوت ما با بقیه :(
@one_programmer

@one_programmer

‏حدیث داریم میگه DevOps های خوب تو قیامت با دولوپر های Senior محشور میشن و DevOps های بد با Junior ها
@one_programmer

@one_programmer
یه کتاب خیلی خوب در مورد ASP.NET Core 2.0

The Little ASP.NET Core 2.0 Book

https://www.recaffeinate.co/book/

@one_programmer

@one_programmer
ماکروسافت از سورس کنترل Git برای توسعه ویندوز استفاده میکنه !
بزرگ ترین repo در دنیا :)
300 گیگ حجم و بیش از 3.5 میلیون کد
و بیش از 4400 برنچ(Branch) فعال
و....
https://fossbytes.com/microsoft-uses-git-windows/

@one_programmer

@one_programmer
عادات افراد ناموفق

@one_programmer

@one_programmer
مقاله ای خیلی جالب تحت عنوان "مواردی که در سال اول کارم در گوگل در مورد API ها یاد گرفتم"
نویسنده در قسمتی از متن به آمار API Call های دیتاسنترهای گوگل اشاره میکند, ۱۰ میلیارد API Call در ثانیه !
همچنین به چالش ها و ابزار هایی خاصی که با اون کار کرده

@one_programmer

https://medium.com/apis-and-digital-transformation/i-got-a-golden-ticket-what-i-learned-about-apis-in-my-first-year-at-google-556e1f02f9ab

@one_programmer
#پنج_آدمخوار
داستان طنز

پنج آدمخوار به عنوان کارمند در یک اداره استخدام شدند.
هنگام مراسم خوشامدگویی رئیس اداره گفت: شما همه جزو تیم ما هستید. شما اینجا حقوق خوبی می گیرید و می توانید به غذاخوری شرکت رفته و هر مقدار غذا که دوست داشتید بخورید. بنابراین فکر خوردن کارکنان دیگر را از سر خود بیرون کنید.

آدمخوارها قول دادند که با کارکنان اداره کاری نداشته باشند. چهار هفته بعد رئیس اداره به آنها سر زد و گفت: می دانم که شما خیلی سخت کار می کنید. من از همه شما راضی هستم. اما یکی از نظافت چی های ما ناپدید شده است. کسی از شما می داند که چه اتفاقی برای او افتاده است؟ آدمخوارها اظهار بی اطلاعی کردند.

بعد از اینکه رئیس اداره رفت، رئیس آدمخوارها از بقیه پرسید: کدوم یک از شما نادونا اون نظافت چی رو خورده؟
یکی از آدمخوارها با اکراه دستش را بالا برد.
رئیس گفت: ای احمق! طی این چهار هفته ما مدیران، مسئولان و مدیران پروژه ها را خوردیم و هیچ کس چیزی نفهمید و حالا تو اون آقا را خوردی و رئیس متوجه شد؟!

از این به بعد لطفاً افرادی را که کار می کنند نخورید.
@one_programmer

@one_programmer
ویندوز ۹ و آیفون ۹ :)

@one_programmer

@one_programmer

پروسه تولید نرم افزار تو ایران :)


۱- برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است .😏

۲- محصول تست میشه و ۲۰ تا باگ پیدا میشه . 😐

۳- برنامه نویس ۱۰ تا از اون خطاها رو حل میکنه و برای بخش تست نرم افزار هم توضیح میده که اون ۱۰ تای دیگه واقعا باگ نیستند . 😌

۴- بخش تست در هنگام تست محصول ۵ تا باگ دوباره از اون ۱۰ تایی که حل شده بود پیدا میکنه و علاوه بر اون ۱۵ تا باگ جدید دیگه 😒

۵- مرحله ۳و۴ سه بار تکرار میشه .🙄

۶-بخش فروش به برنامه نویس ها و تسترها فشار میاره که زودباشید نرم افزار رو ارایه کنید و این گونه میشه نرم افزار به دست کاربر میرسه . 🤒

7-کاربر 137 تا باگ جدید پیدا میکنه . 😬

8-برنامه نویس های اصلی تولید این محصول باهاشون تسویه میشه و همشون از کار برکنار میشند . 🤕

9-تیم برنامه نویسی جدید تقریبا تمام اون 137 تا باگ رو رفع میکنند اما باعث به وجود اومدن 456 تا باگ جدید میشند. 😲

10-شرکت مجبور میشه از یه شرکت دیگه برنامه نویس قرض کنه تا این 738 تا باگ رو رفع بکنند . 😑

11-برنامه نویس خبره که از اون یکی شرکت اومده این کدها رو قبول نداره و میگه باید از اول بنویسه . 😶

12-برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است . 😷

و این جریان ادامه دارد…😂

@one_programmer

@one_programmer

ابزار محاسبه‌گر درآمد Stack_Overflow

ابزاری برای محاسبه اینکه فردی با توانایی‌ها و مهارت‌های شما در یکی از کشورهای پیشرفته چه میزان درآمد دارد.
https://stackoverflow.blog/2017/09/19/much-developers-earn-find-stack-overflow-salary-calculator/

@one_programmer

@one_programmer

مقاله ای از سایت GitLab در مورد چالش های این سایت در Scale کردن دیتابیس ها و همچنین راه حل به کار گرفته شده ی آن ها
https://about.gitlab.com/2017/10/02/scaling-the-gitlab-database/

@one_programmer

@one_programmer

مقاله جالبی درمورد اینکه کدام زبان برنامه نویسی بیشتر مستعد به تولید کد های باگ دار است؟؟

https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/fulltext

@one_programmer

@one_programmer

آمار زبان هایی مثل go, php, python, #c جالبه

لینک پست: https://t.me/one_programmer/115

@one_programmer

@one_programmer

چگونه بازماندگان شما را فریب می‌دهند؟
نویسنده: فرزاد مینویی
تصمیم_گیری

در خلال جنگ جهانی دوم، نیروی هوایی انگلستان و آمریکا به دنبال کاهش تلفات بمب افکن های خود بودند. رهبران نظامی به این نتیجه رسیده بودند که باید زره تقویتی بیشتری به هواپیماهای خود اضافه کنند تا آن‌ها را در برابر آتش ضدهوایی و جنگنده‌ها حفاظت کند؛ اما افزودن زره به همه قسمت‌های هواپیما امکان‌پذیر نبود و سرعت آن را کم می‌کرد؛ بنابراین آنان باید تصمیم می‌گرفتند که به کدام قسمت‌های هواپیما زره بیفزایند.

برای این منظور آنان شروع به جمع آوری داده کردند. پس از هر مأموریت هواپیماهایی را که بازگشته بودند به‌دقت بررسی می کردند و تعداد آسیب‌های ناشی از ترکش‌ها و گلوله‌ها و جای آن‌ها را روی هواپیما مشخص می کردند. به‌تدریج معلوم شد الگوی خاصی در توزیع آسیب‌ها روی هواپیما وجود دارد. بیشتر آسیب‌ها روی ناحیه بال و بدنه هواپیما بود. بر این اساس کارشناسان نظامی نتیجه‌گیری کردند ازآنجاکه بیشترین گلوله‌ها به نواحی بال و بدنه هواپیما اصابت کرده پس این قسمت‌ها نیازمند زره حفاظتی بیشتر هستند. در نگاه اول این نتیجه‌گیری درست به نظر می‌رسد.

آبراهام والد با این نتیجه‌گیری کاملاً مخالف بود. او جزء ریاضی‌دانی بود که در جنگ جهانی دوم برای ارتش آمریکا کار می‌کرد. والد نشان داد که خطای مهمی در تحلیل‌ها صورت گرفته چراکه نتیجه‌گیری تنها بر اساس داده‌های هواپیماهایی است که از مأموریت بازگشته‌اند؛ اما در مورد هواپیماهایی که در طول مأموریت سقوط کردند، چه می‌دانیم؟ او نشان داد که دقیقاً برعکس، آن قسمت‌هایی از هواپیما نیاز به حفاظت دارند که کمترین اصابت را داشته‌اند. درواقع نقاط آسیب در هواپیماهای بازگشتی بیانگر آن است که اگر هواپیما در این نقاط هدف قرار داده شود، با احتمال بیشتری می‌تواند سالم بازگردد. پیشنهاد‌های والد در عمل به بهبود نرخ برگشت هواپیماها کمک کرد.

سوگیری بازماندگی (Survival Bias) یک خطا در استدلال است و زمانی پیش می‌آید که تنها بر روی افراد یا چیزهایی که از یک فرآیند انتخاب گذشته‌اند، تمرکز کنید و آن‌هایی را که نتوانستند عبور کنند، عمدتاً به این خاطر که دیگر قابل‌مشاهده نیستند، نادیده بگیرید.

به‌عنوان‌مثال، ساختمان‌های با ساخت مستحکم، معماری زیبا، کاربری خوب و نگهداری مناسب در چندین نسل دوام می‌آورند و باقی می‌مانند. افراد ممکن است تنها با مقایسه ساختمان‌های قدیمی باقی‌مانده با ساختمان‌های امروزی این‌طور نتیجه بگیرند که درگذشته ساختمان‌های بهتری ساخته می‌شده است؛ اما آنان هزاران بنای دیگر را که درگذشته خوب ساخته نشده‌اند و در طول زمان از بین رفته‌اند و دیگر قابل‌مشاهده نیستند، در نتیجه‌گیری خود لحاظ نمی‌کنند. این سوگیری می‌تواند برای آثار هنری برجسته گذشته که در طول زمان از رقابت سربلند بیرون آمده‌اند و مقایسه آن با آثار هنری معاصر مصداق پیدا کند. یکی از دلایل وجود حس نوستالژی نسبت به گذشته این نوع مقایسه‌هاست.

می خواهید استیو جابز بعدی باشید؟ از دانشگاه انصراف بدهید و با یکی از رفقای خود در گاراژ خانه پدری یک کسب و کار راه بیندازید! اما چند نفر مدل استیو جابز را جلو رفتند و شکست خوردند؟ کسی نمی داند، درباره آنها کتابی نوشته نمی شود کسی آنها را نمی بیند. اما براساس اتحادیه سرمایه گذاران خطرپذیر آمریکا تنها 13 درصد استارتاپ ها به مرحله عرضه سهام خود در بورس می رسند یا می توانند آن را بفروش برسانند.

من در مقاله زیر نشان می دهم چطور کتاب های موفقیت مانند "از خوب به عالی" جیم کالینز به طور سیستماتیک دارای خطا هستند.

این مثال‌ها روشن می‌کند که برای نتیجه‌گیری نیاز دارید تا به همه نمونه‌ها توجه کنید حتی نمونه‌هایی که بلافاصله نمی‌توانید آن‌ها را مشاهده کنید. همین‌طور روشن می‌کند یادگیری از شکست‌ها همواره فرآیند ساده‌ای نیست. یادگیری نیازمند مشاهده و بررسی دقیق و فراتر رفتن از فرضیات سطحی است. وقتی تنها به نمونه‌های موفق نگاه می‌کنید ممکن است از رفتارها و اشتباهات مهلکی که نمونه‌های ناموفق به آن دچار شدند، غفلت کنید. شاید به همین دلیل است وقتی از آن حکیم پرسیدند “ادب از که آموختی؟” پاسخ داد: “از بی‌ادبان”.

@one_programmer