اتم: ادیتور دوست داشتنی

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

نرم افزار ویرایشگر اتم

۲. این که IDE به ادم کمک کنه خوبه. ولی به چه قیمتی؟ اتفاقی که واسه دات نتی ها میفته اینه که بدون ویژوال استودیو تقریبن نصف مهارت برنامه نویسی خودتشون رو از دست می‌دن. چرا؟ چون از همون اول بد عادت می‌شن،‌ وابسته می‌شن به ویژوال استودیو. البته این درمورد جاواکار ها و اینتلیجی، اندرویدیا و اندروید استودیو، پایتون و پایچارم و  در کل هر زبون و IDEای صادقه.

۳. اتم رو خیلی دوست دارم. یه ادیتور ساده با کلی ویژگی خوب. اولین خوبیش اینه که – مخصوصن توی پروسه یادگیری- مجبور میکنه برنامه نویس رو که همه چیز رو خودش بنویسه. البته یه سری کمک می کنه ها. ولی خب اینا اسمشون کمکه، نه این که بیاد کل کار رو از رو دوش برنامه نویس برداره.

۴. چیزی که اتم رو دوست داشتنی می‌کنه، پلاگین های خوبیه که داره. این پلاگین ها شاید همون چیزایی رو به اتم اضافه کنن که ویژوال استودیو و امثالش از همون اول دارن. ولی نگته دقیقن همین جاست. برنامه نویس بعد از یه مدت کار کردن و سر و کله زدن با ادیتورش به اینا برمی خوره و وقتی ازشون استفاده می کنه که هم یاد گرفته که بدون اونا کار کنه و هم واقعن نیاز رو درک می کنه. توی این مطلب چند تا پلاگین خوب و کاربردی برای اتم هم معرفی می‌کنم.

 

چرا پایتون؟

۱. سوالی که خیلی وقتها از من پرسیده می‌شه اینه: چرا پایتون؟ چرا پی اچ پی نه؟ چرا دات نت نه؟ چرا جاوا نه؟ خب جوابهای متنوعی هست که می‌شه به این سوال داد. این جا یکیش رو می نویسم و امیدوارم که فرصت بشه از هر زاویه‌ای بررسیش کنم.

لوگو زبان برنامه نویسی پایتون

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

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

۴. کد‌های زیر رو نگاه کنید:

پایتون در مقابل سی و جاوا

مثال معروف سلام دنیا که توی سی و جاوا به اون هم نوشتن نیاز دارن توی پایتون با یه خط قابل انجام دادنه. البته که نمی‌شه نتیجه گرفت که مثلن یه برنامه ۱۰۰۰ خطی توی جاوا، با پایتون توی ۲۰۰ خط قابل انجامه. اما چیزی که می‌شه نتیجه گرفت اینه که پایتان به شدت ما رو از نوشتن قسمت‌های زاید و حوصله سر بر برنامه خلاص می کنه. این خوبه. واقعن خوبه. این به برنامه‌نویس این امکان رو می‌ده که روی قضیه‌ی اصلی تمرکز کنه. این به شدت سرعت توسعه نرم افزار رو بالا می  بره.

۴. توی مطالب بعدی احتمالن برم سراغ گستردگی حوزه‌هایی که پایتون توشون قابل استفاده‌س. همینطور اینکه کجا و چرا باید پایتون رو به مثلن جاوا ترجیح داد و چیزای دیگه‌ای از این دست. اگر برنامه‌نویس و مخصوصن برنامه‌نویس پایتون هستید ممنون می‌شم تجربیاتتون درمورد پایتون رو برام کامنت کنید یا توی به جیمیل resa.keshavarz بفرستید (به املای ادرس حتمن دقت کنید). شاید بتونیم با همفکری پایتون رو جور بهتری معرفی کنیم به تازه برنامه‌نویس ها یا اونایی که هنوز از پایتان زیاد آگاه نیستن.

 

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

۹۷ چیزی که هر برنامه نویس باید بداند

۱. کتابیه که اسمش کاملن واضح می‌گه محتوا چیه:‌ نود و هفت چیز که یه برنامه نویس باید بدونه. یا بهتره بگیم نود و هفت نکته که دونستنش به یه برنامه نویس کمک می‌کنه که برنامه نویس بهتری بشه. کارهای خورد و ریزی مثل کامنت گذاری و اهمیتش و شیوه‌ی درست انجام دادنش گرفته تا اهمیت استفاده از نرم افزار های ورژن کنترل(مثلن گیت) برای توسعه نرم افزار. یا مثلن این که کد زدن و مهارتهای مهندسی تنها عاملهای موفقیت نیستن و چیزای دیگه ای هم هستن که یه برنامه نویس باید حواسش بهشون باشه. درکل کتابیه که به شدت به هر کسی که برنامه نویسه یا می ‌خواد برنامه نویس باشه توصیه می‌شه. این رو هم بگم که هیچ کدوم از این نود و هفت چیز بیشتر از دو صفحه نیستن و خب زمان زیادی رو از آدم نمی گیرن. پیشنهاد شخصی من هم البته اینه که وقتی برین سراغ این کتاب که حداقل روی یه زبان برنامه نویسی مسلط باشین و یکی دو تا پروژه (چه بهتر که تجاری/واقعی/کاربردی باشن ولی پروژههای تمرینی هم قبوله) انجام داده باشین و تا حدودی با پروسه تولید نرم افزار آشنا باشین. این رو هم بگم که کتاب کاملن رایگان هست و هم روی گیتهاب و هم توی خیلی از سایتهای دانلود کتاب می‌تونید با خیال راحت پیداش کنید و دانلود کنید.

۹۷ چیزی که هر برنامه نویس باید بداند

۲. این جا تعدادی از تیتر ها رو می ذارم که شاید جذاب تر کنه خوندن کتاب رو:

  •  رعایت اصول بنیادی برنامه‌نویسی
  • از خود بپرسید کاربر – در این موقعیت- چکار خواهد کرد!‌ (شما کاربر نیستید)
  • زیبایی در سادگی ست
  • قانون پیشاهنگی
  • ابزار‌های خود را با دقت انتخاب کنید
  • مرور کد
  • کامنتی درباره کامنت ها
  • تنها چیزی را کامنت کنید که کد نمی تواند بیان کند
  • یادگیری مستمر
  • از خراب کردن چیزها نترسید
  • با دیتای تست نرم رفتار نکنید
  • ارور ها را نادیده نگیرید
  • به یاد گرفتن یک زبان بسنده نکنید،‌ فرهنگ آن را هم درک کنید
  • خودتان را تکرار نکنید
  • و …

اینا چندتا از تیترا بودن که توی هرکدوم البته نکته‌های ریز فرعی دیگه‌ای هم پیدا می‌شه. جالبیش اینه که بعضی تیترا یکمم ادبی شدن. یه چیز خوبی هم که این کتاب داره اینه که علاوه بر این که می تونید سر تا تهش رو بخونید، درصورتی که به موضوع خاصی علاقه دارید یا به اطلاعات نیاز دارید می تونید از فهرست موضوعیش استفاده کنید که ۹۷ تا مقاله رو تقسیم کرده به به چند تا دسته. مثلن یه دسته درمورد دیباگ کردن داره، یه دسته درمورد طراحی، یه دسته برای بهینه سازی و پرفورمنس و… .

اوپن سورس معنیش این نیست که همین الان می‌تونم عوضش کنم

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

اوپن سورس - متن باز

۲. یکم فنی‌تر: پروسه‌ی تولید یک نرم‌افزار تقریبن اینجوریه:

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

۳. نکته درواقع اینه: کد ماشین قابل ویرایش نیست(می‌شه درواقع ولی خیلی خیلی سخت و پردردسره) . برنامه‌های بسته(مخالف متن‌باز ها منظورمه) این فایل نهایی رو در اختیار کاربر می‌ذارن. اوپن سورس ها اما، کد تولید شده توی مرحله‌ی اول رو هم به‌صورت عمومی منتشر می‌کنن. این یعنی چی؟ یعنی مثلن من که با برنامه‌نویسی آشنام می‌تونم این کد رو بردارم و تغییر بدم و کامپایل کنم و اجرا کنم. ولی این به هیچ وجه معنیش نیست که می‌تونم اون برنامه‌ای که همین الان روی کامپیوترم نصبه رو تغییر بدم. به هیچ وجه.

 

 

  • احتمالن بازم برم سراغ این جور مطالب که برای آدم‌های نسبتن مبتدی و نااشنا به دنیای کامپیوتر‌ها مفید باشه. گیک‌ها تکلیفشون معلومه: این مطلب چیزی براشون نداره. بی‌علاقه‌ها به دنیای کامپیوتر هم همینطور: حوصله‌شون سر‌میره. مخاطب این متن اونایی‌ان که تازه دارن وارد دنیای قشنگمون می‌شن وهنوز یه سری ابهام براشون وجود داره.

به زبان آدمیزاد URL بنویسیم

۱. اتفاقی که افتاده اینه: یکی از دوستای من وقتی می خواسته حساب تپسی خودش رو شارژ کنه یه صفر اضافه می ذاره و به‌جای بیست هزار تومن، دویست هزار تومن شارژ می‌کنه حسابش رو. توی پروسه‌ی استرداد پولش، به یه لینک می‌رسه که اینجوریه:

https://tap30.ir/php/__123_send_email.php

۲. توی این یه دونه ‌URL چندتا نکته‌ی خیلی باحال دیده می‌شه. اولین چیزی که توی ذوق می‌زنه، اون ۱۲۳ هست که توی اسم فایل پی اچ پی هست. دلیلش رو می‌شه تا حدودی حدس زد. یا یه فایل به اسم send_email از قبل وجود داشته و آقا/خانم برنامه‌نویس بی‌حوصله، اینجوری از زیر بار اسم انتخاب کردن در رفته. ولی شایدم می‌خواسته مفهوم خاصی رو با این اسم برسونه که بازهم متاسفانه چندان واضح نیست و موفق نبوده. در مورد اون دو تا آندر-اسکور اول اسم فایل هم نمی دونم بین پی‌اچ‌پی کار‌ها مفهومی داره یا این‌که این‌هم از خلاقیت(!)‌های این برنامه‌نویسه.

۳. توی URL بالا یه چیز جالب دیگه هم دیده می‌شه: اون فایل پی‌اچ‌پی که بحثش شد، توی فولدری قرار گرفته به اسم PHP. این هم اصلن چیز جالبی نیست. از هر منظری به قضیه نگاه کنیم این کار غلط حساب می‌شه. اولین نکته اینه که مخاطب سایت ما که در اکثر موارد برنامه نویس نیست و یه آدم معمولیه، چندان سودی نمی بره از دیدن این اسم فولدر. حتی برای برنامه‌نویس‌ها هم جالب نیست دیدن همچین چیزی. کار درست و خوشبختانه رایج اینه که اسم این فولدرها، تابع کاری که انجام می‌دن باشه. یعنی جوری که با دیدن آدرس یه صفحه که شامل اسم فولدر و اسم فایل می‌شه، کاربر بتونه درمورد حاصلی که قراره ببینه حدس بزنه. از این هم بگذریم از تاثیر آدرس صفحه‌ها توی سئو سایت نباید ساده رد شد. اینجا این رو می‌فهمیم که آقا/خانم برنامه‌نویس درمورد سئو هم اطلاعات چندان درست و دقیقی نداره. و تلخ‌تر اینکه این مسائل رو داریم توی سایتی شرکتی می‌بینیم که جزو شرکتای به‌روز بازار ایران حساب ‌می‌شه.

۴. قضیه به ‌َیه ‌URL بد ختم نمی‌شه. با باز کردنش می‌رسیم به این صفحه:

tap30

این ‌مشکل رو توی تقریبن همه‌ی مرورگر‌ها می‌شه دید. جالب اینه که همچین مشکلی حتی توی بی‌کیفیت‌ترین سایت‌ها هم به ندرت پیش می‌اد.

  • چیزی که اینجا -توی URL- ازش به عنوان فولدر/پوشه حرف زده شد، درواقع می‌تونه حتی فولدر هم نباشه. خیلی از فریمورک ها – از جمله‌ جنگو- این امکان رو می‌دن که برنامه‌نویس بسته به نیازش و چیزی که توی ذهن داره، آدرس‌ها رو تعریف کنه. درمورد URL Pattern و URL Mapping جستجو کنید.

استارت‌آپ و با کله سقوط کردن و سیلیکون ولی

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

startup

۲. اولین چیزی که توی این پیشنهاد توی ذوقم خورد،‌ این بی-درنگ-پیشنهاد-دادن بود. حتی حاضر نبود چنددقیقه صبر کنه تا باهام یکم بیشتر آشنا شه و اندکی محک بزنه منو.

۳. دومین چیزی که خیلی آزاردهنده بود، فعالیتشون بود: فروشگاه آنلاین مبلمان! متاسفانه تعریف درستی از استارت‌آپ وارد بازار کار ایران نشده. به طرز سطحی نگرانه‌ای،‌هر کسب و کار نوپا و از-صفر-شروع-شده-ای رو استارت‌آپ باید قلمداد کرد گویا.

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

۵. تلخ ترین قسمت ماجرا شاید اینجا باشه: این استارت‌آپ‌ها ( هم اونایی که با هدف نیروی کار ارزون اسم استارت‌آپ رو استفاده می‌کنن و هم اونایی که بخاطر تعریف نادرست، خودشونو استارت‌آپ می‌دونن) بعد از یه مدت نه چندان طولانی با کله سقوط می‌کنن. اتفاقی که میفته اینه که بخاطر نداشتن درک درستی از فعالیتشون و استفاده از آدم‌های نادرست (کسایی که روحیه استارت‌آپی ندارن)  هیچ وقت به اون مقصد دلخواه نمی‌رسن. علاوه بر‌ اینها،‌بی تجربه بودن،‌ تصمیم گیری‌های احساسی و نسنجیده و خیال‌پردازانه و بیش از حد خوش بینانه برنامه‌ریزی کردن هم چندتا از مشکلاتیه که – حد اقل توی مواردی که من دیدم – به شدت پررنگ بودن.

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

silicon valley

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

 

ایده همه چیز نیست

۱. یکی از کارهایی که من مدتی مشغولش بودم برنامه‌نویسی اندروید بوده. توی این چند سال چیزی که خیلی باهاش برخورد کردم دوست و آشنایی بوده که اومده و گفته که ایده‌ی ناب و بکری داره و می‌خواد اجراش کنه و نیاز به برنامه نویس داره. توقعشم این بوده که از اونجایی ایده‌ش خیلی ناب و عالیه من همه‌ی کار‌ها رو انجام بدم و ایشون فقط بخاطر ایده‌ای که داشته سهم برابری با من داشته باشه از حاصل.

۲. یکی از چیزهایی که خیلی می‌شنویم اینه که ایده خیلی مهمه. اکثر غیر-کامپیوتری‌ها و حتی بعضی از کامپیوتری‌ها و برنامه‌نویس‌ها ایده رو مهم ترین رکن یه پروژه‌ی موفق می‌دونن.  این‌که ویندوز دنیای دسکتاپ رو تسخیر کرده، این‌که اینستاگرم اینقدر محبوب و رایج شده، این‌که گوشی‌های اپل اینقدر پرفروش و محبوبن، و در‌کل هر موفقیتی که توی این این دنیا بدست می‌آد از دید این جور افراد فقط و فقط بخاطر ایده‌ی خوبیه که در ابتدا داشتن.

۳. جادی – که لینوکسی‌ها و دنبال‌کننده‌های دنیای نرم افزار آزاد احتمالن باهاش آشنا هستن –  توی بلاگش مطلب جالبی گذاشته و توی یه تصویر  اومده و میزان تاثیر ایده ی خام توی ارزش کلی پروژه رو با یه فرمول(!) ساده توضیح داده. فکر نمی‌کنم تصویر نیازی به توضیح داشته باشه:

idea