بایگانی برچسب: s

توسعه عملیات، مدیریت سیستم، استقرار و یکپارچگی

در دنیای امروزی، بخش بسیار بزرگی از بیزنس و همچنین توسعه نرم‌افزار مرتبط به توسعه عملیات (Dev Ops)، مدیریت سیستم (System Administration) و همچنین استقرار و یکپارچگی ادامه‌دار (CI/CD) میشه. شاید حتی مهم‌تر از اصل نرم‌افزار، رسیدگی به این موضوعات باشه. در این پست، قراره که با هم بررسی کنیم چطور میتونیم در پایان روز، به خودمون بگیم DevOps Engineer؟ و چه چیزایی باید بلد باشیم؟ 🙂

مدیریت سیستم یاد بگیرید

یادگیری مدیریت سیستم، بخش «عملیات» قضیه رو معمولا شامل میشه. پس لازمه که اینجا چیزایی رو بلد باشیم که معمولا در شرکت‌ها و سازمان‌های بزرگ بهشون نیاز میشه. اما قبل از اون، لازمه که یه چیزایی رو به صورت عمومی بلد باشیم. پس بیاید با هم بررسی کنیم که عمومیات دواپس شدن چیا هستن؟

  • یادگیری لینوکس. عموم شرکت‌ها در دنیا در حال حاضر، سرورهای لینوکسی دارند. بلد بودن لینوکس، یک «باید» در یادگیری دواپس محسوب میشه. یادگیری لینوکس اصلا سخت نیست. کافیه یک توزیع خاص (مثل اوبونتو) رو نصب کنید و باهاش بازی کنید. کم کم دستتون میاد که چی به چیه. بعد از این ماجرا، میتونید یک سرور اجاره کنید و چیزایی که یاد گرفتید رو روش تست کنید.
  • آشنایی با وب‌سرورها. وب‌سرورها، نرم‌افزارهایی هستند که به شما امکان نمایش نرم‌افزار و محتوای تولیدی از طریق پروتکل HTTP رو میدن. در دنیای امروز اکثریت قریب به اتفاق کسب و کارهای کوچک و حتی بزرگ، از NGINX استفاده می‌کنن. پس بد نیست بعد از این که لینوکس یاد گرفتید، روی سرور یا ماشین مجازی لینوکسیتون یک وب‌سرور نصب کنید و سعی کنید یک صفحه استاتیک باهاش نمایش بدید.
  • آشنایی با شبکه. گرچه معمولا این مورد رو باید اول از همه بیاریم، اما من شخصا معتقدم که یادگیری لینوکس در بحث مدیریت سیستم به هرچیزی ارجحه. اما از این موضوع که بگذریم، چرا شبکه؟ شبکه پایه و اساس دواپسه. شما بدون بلد بودن شبکه، تقریبا هیچ کاری نمی‌تونید بکنید. اما چه حد شبکه بلد بودن خوبه؟ دقت کنید که اینجا قرار نیست ما نیروی آی‌تی یک سازمان باشیم، پس فقط کافیه که پایه‌های شبکه، آی‌پی و بعضی پروتکل‌های مرسوم (SSH, FTP, HTTP, SMTP و …) رو بدونیم و بدونیم که هرکدوم چطور و کجا کار می‌کنند.
  • آشنایی با فایروال و تامین امنیت شبکه. فکر کنم عنوان خودش گویاست. در لینوکس، ما معمولا از iptables یا اینترفیس‌هایی که براش ساخته میشن (مثلا اوبونتو UFW و دبیان apparmor رو دارند) استفاده می‌کنیم. این خیلی مهمه که شما بعنوان مدیر سیستم، در جریان باشید که چه چیزایی از بیرون در دسترسه و این حجم از دسترسی، چقدر میتونه آسیب‌زا باشه.

موارد بالا، مواردی هستند که حتما باید بلد باشید. فرقی هم نمی‌کنه که جایی استخدام شدید یا اگر قراره بشید، ازتون خواستند بلد باشید یا نه. در واقع «باید»های مدیریت سیستم موارد بالان.

اما در بسیاری از شرکت‌ها یک سری سناریو خاص وجود داره که این‌ها رو میتونیم با هم بررسی کنیم، گرچه قرار نیست همه موارد رو با هم یاد بگیریم، اما چیزایی که به نظرم ممکنه وجود داشته باشند رو در اینجا بررسی می‌کنم.

  • استفاده از یک ابر خصوصی به جای چندین سرور عمومی. این مورد، مورد خوب و امنیه. گذشته از این که باعث میشه خیلی از موارد (مثل دیتابیس و …) از بیرون در دسترس عموم قرار نگیرند، هزینه‌ها رو هم پایین میاره. فقط حواستون باشه که در این مورد، معمولا چند چیز اتفاق می‌افته که باید بلد باشید:
    • استفاده از لود بالانسر : لود بالانسرهای مرسوم مثل haproxy میتونن نقطه شروع خوبی باشن. البته این هم در نظر داشته باشید که معمولا ارائه‌دهندگان سرویس‌های ابری؛ خودشون هم لود بالانسینگ رو انجام میدن.
    • استفاده از سیستم‌های مانیتورینگ : طبیعتا شما برای این که ببینید هرکجا چه اتفاقاتی می‌افته، نیاز به یک سیستم مانیتورینگ خوب دارید. در حال حاضر سرویس‌هایی مثل prometheus و zabbix وجود دارند. همچنین میتونید اینها رو به grafana و امثالهم متصل کنید و به شکل زیبایی، اونها رو ویژوالایز کنید.
  • استفاده از نرم‌افزارهای بیلد شده به صورت سفارشی. گرچه این مورد رو شخصا درک نمی‌کنم (چون نسبت به نرم‌افزاری که از کانال رسمی – مثل مخزن‌های توزیع لینوکستون – نصب می‌کنید ممکنه امنیت و پایداری کمتری نشون بدن) اما برخی سازمان‌ها ممکنه وب‌سرور، کامپایلر یا مفسر یا حتی کرنل رو خودشون از نو بیلد کرده باشن. پس یادتون باشه این مورد هم تا حدی یاد بگیرید که اگر نیاز به بیلد مجدد شد گیر نکنید 😁

در مورد مدیریت سیستم به قدر کافی یاد گرفتیم، دیگه چی می‌مونه؟ نظر من رو بخواید الان وقتشه که یک سری ابزار رو با هم بررسی کنیم. توجه کنید که ابزارهایی که در این بخش ازشون حرف می‌زنم، ابزارهایی هستند که خودم باهاشون تجربه کار دارم. فلذا اگر ابزاری از قلم افتاده، در بخش نظرات در مورد ابزارهای مورد نظر خودتون صحبت کنید. من خوشحال میشم 🙂

ابزارهایی که باید یاد بگیرید

وب‌سرور

گرچه این رو در بخش قبلی اشاره کردم، در اینجا میخوام صرفا کمی در مورد NGINX حرف بزنم. یادتون باشه که NGINX امروزه یک انتخاب خوبه چون:

  • در بسیاری از توزیع‌ها، وجود داره. در حدی که خیلی از توزیع‌های سروری رو وقتی نصب کنید؛ ممکنه همراهش نصب شده باشه.
  • پیکربندی به شدت ساده‌ای داره (و خب کاش حداقل نیاز نبود ته هر خط پیکربندی شما یک سمی‌کالن بذاری)
  • ابزارهای جانبی بسیار خوبی مثل python3-certbot-nginx براش ساخته شده که امکان SSL و … گرفتن برای دامنه خاص و زیردامنه‌ها و … رو به شدت ساده می‌کنه.
  • تقریبا برای هرکاری یه آموزشی ازش هست!

ابزارهای CI/CD

خب ابزارهای CI/CD چی هستند؟ به صورت کلی، این ابزارها اینجان که کار استقرار (Deploy) و یکپارچگی (Integration) هرآپدیت با نسخه قبلی رو اتوماتیک انجام میدن. ابزارهای زیادی برای این کار وجود دارند من جمله Travis CI, Jenkins و البته معروف‌ترینشون Gitlab CI/CD (حداقل در ایران).

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

ابزارهای مانیتورینگ

طبیعتا بالا بودن یا نبودن سرویس‌ها، دیتابیس، سرویس‌هایی که از بیرون دریافت می‌کنیم و یکپارچگی داریم باهاشون، مهمن. همینطور ظرفیتی که در دیسک و حافظه و … اشغال شده هم مهمه که دونسته بشه. فلذا اینجا لازمه که ابزاری باشه که اینجا بیاد و این رو برای ما چک کنه.

این ابزار معمولا چیه؟ خب ابزارهای زیادی براش هست و من تجربه‌م استفاده از prometheus بوده. پرومتئوس یک سری ابزار خاص داره که بهش میگن exporter. شما روی هر قسمتی که نیاز دارید (مثلا nginx یا خود سرور که بهش میگن node یا هرچیزی از این قبیل) یک اکسپورتر نصب کنید و نتایج آنالیزها رو اینجا ببینید.

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

ابزارهای ذخیره‌سازی

خب، این هم یه چیزی که شاید کمتر ازش با خبر بوده باشید :). در دنیای امروز تقریبا کسی نیست که رو همون سروری که نرم‌افزارش هست، فایل ذخیره کنه. پس چی کار می‌کنن؟ هیچی، اونجاهایی که جزء دنیا حساب میشن؛ معمولا از Amazon AWS استفاده می‌کنن و پارتیشن S3 دریافت می‌کنن. S3 یعنی Simple Storage Solution (سه تا S) و خب این حقیقت وجود داره که راهکار بهتریه. چرا؟ چون شما برای ذخیره‌سازی صرفا هارد نیاز داری و نه پردازنده یا رم زیاد.

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

یک راه دیگه هم داشتن سرور با حجم بالای هارددیسک (در ابعاد ترابایت) میتونه باشه. بعد از اون شما نیاز دارید تا یک نمونه S3 روی اون مستقر کنید. برای این کار میتونید از ابزاری مثل minio بهره بگیرید.

ابزارهای ارکستراسیون

ابزارهای ارکستراسیون چی هستند؟ ارکستر در موسیقی، به معنای «گروهی از نوازندگان»ــه. یعنی یک گروهی که مثلا دو نفر ویولن میزنن، یک نفر ویولا و یک نفر چلو. در دواپس ارکستر به مجموعه‌ای از سرورها یا شبکه‌ها گفته میشه که یک کار انجام میدن. تا حالا دقت کردید چطوریه که شما سرعت کارتون با توییتر در آلمان با سرعت کارتون با توییتر در آمریکا یکیه؟ یا مثلا چطوریه که شما از ایران یک عکس رو پست می‌کنید و مثلا خاله شما در آمریکای شمالی اون رو لایک می‌کنه؟!

علتش اینه که این نرم‌افزارها به عبارتی Orchestrate میشن (فارغ از بحث CDN و …) یعنی از یک نرم‌افزار و همچنین دیتابیسشون (البته دیتابیس Cache و نه دیتابیس‌های اصلی) بیش از یک نمونه در حال اجراست. برای شما سوال نشده که اینا چطور هندل میشن؟ خب جواب اینه که ابزارهای ارکستراسیون استفاده میشه.

از بین این ابزارها میشه به Docker Swarm و Kubernetes و Ansible اشاره کرد. طبق تجربه با Ansible به شما بگم که شما تنظیماتی که نیاز دارید رو مشابه CI/CD در یک سری فایل پیکربندی (انسیبل بهشون میگه استوری) می‌نویسید و مجموعه‌ای از استوری‌ها رو در یک namespace قرار می‌دید. مثلا فرض کنید همین وبلاگ کجاها قراره باشه، من یه namespace به اسم haghiri75 میسازم و اطلاعات استقرار رو بهش میدم.

با ابزارهای ارکستراسیون، آماده‌سازی و پیاده‌سازی سناریوهای سرور و یا ابر خصوصی به شدت ساده‌تر و سریع‌تر خواهد شد.

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

برنامه‌نویسی یاد بگیرید

بسیار خوب، در این بخش که در واقع بخش پایانی این مطلب در مورد اینه که چطور DevOps بشیم، لازمه اشاره کنم به این که نیاز دارید برنامه‌نویسی بلد باشید. حالا به چه زبونی و در چه حد؟ اینها مهمن. خب در این قسمت یکم در مورد زبان‌هایی که «باید» بلد باشید صحبت می‌کنم و بعد از اون هم راهنمایی می‌دم در مورد زبان‌هایی که احتمالا در جریان کار مجبورید باهاشون کار کنید.

پایتون، از چیزایی که باید بلد باشید!

چرا پایتون؟ خب پایتون این روزها طوریه که شما حتی مهندس کامپیوتر یا توسعه‌دهنده هم نباشی احتمالا دوست داری یادش بگیری و خیلی‌ها کم و بیش پایتون رو بلدند. اما چرا بعنوان یک مهندس دواپس باید پایتون بلد باشیم؟

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

یک زبان سیستمی

زبانهای سیستمی، زبان‌های برنامه‌نویسی هستند که برای توسعه ابزارهای سیستم‌عامل استفاده میشن، برای تعامل با سخت‌افزار پرفرمنس بهتری دارند و در نهایت برای ایجاد ابزارهای زیرساختی مناسب‌ترند. اینجا نمیخوام شما رو به یادگیری اسمبلی تشویق کنم، بلکه ازتون خواهش می‌کنم همیشه نیم‌نگاهی به زبان‌هایی مثل Rust یا Go داشته باشید (و در نظر بگیرید که Go حتی در بکند هم استفاده میشه فلذا یادگیریش خالی از لطف نیست!).

زبانی که سازمان ازش استفاده می‌کنه

این هم نیاز به گفتن نداره. شما نیاز دارید تا کدبیس رو یاد بگیرید و درکش کنید. حداقل وقتی که قراره دواپسی‌جات رو روی کد اعمال کنید این مهم خودش رو نشون میده. نگران هم نباشید، معمولا DevOps درگیری به شدت کمتری با کدبیس مستقیم درگیر میشه. پس اگر حس و حال کار تو تیم توسعه‌دهنده‌ها رو ندارید نگران این مورد هم نباشید :))

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

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

امیدوارم مطلب مفیدی بوده باشه، در نهایت هم سال نوتون پیشاپیش مبارک 🙂

Share

چطور یک برنامه بنویسیم؟!

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

حالا چرا اینجا؟ در حال حاضر، ابزارهایی مثل ویرگول و مدیوم و dev.to و … اومدند که انتقال تجربه رو هم آسون کردند. اما راستش انتقال تجربه در وبلاگی که سالهای سال اصلی‌ترین محل انتقال تجربه و دانش من بوده، نوشتن مطالبی مثل این، که از جوانب مختلفی اهمیت بالایی دارند اون هم در جای دیگر؛ نوعی خیانت به اینجاست!

خب، هندی‌بازی بسه 😀 بریم سر اصل مطلب.

حقیقتا نوشتن برنامه در دنیای امروز، مثل قدیم برای «حل مسائل ریاضی» نیست. گرچه ما در هر حال، داریم یه مساله‌ای رو به شکل مدلهای متعدد ریاضی درمیاریم که فهمشون رو آسون کنیم؛ اما صرفا ریاضی‌کاری نمی‌کنیم. پس نیازه که اول از همه یه سری مهارت خاص رو در خودمون تقویت کنیم.

تقویت مهارت‌های نرم

شاید مهارت‌های نرم یا Soft Skills ، به صورت مستقیم در نوشتن برنامه مهم نباشند. اما از اونجایی که آداب معاشرت، این که چطور صحبت فنی درستی داشته باشیم، بررسی شرایط روانی خودمون و مشتری و …؛ برای کسایی که میخوان از طریق برنامه‌نویسی و توسعه نرم‌افزار ارتزاق کنند مهم باشه.

بعضی مهارت‌های نرم که در کار برنامه‌نویسی (بعنوان یک شغل) مهمن :

  • آداب معاشرت: راستش این رو من نباید توضیح بدم دیگه :D. و خب آداب معاشرت حتی در فرهنگ‌های مختلف میتونه شکلای مختلفی داشته باشه. پس به نظر میاد لازمه که علاوه بر بلد بودن آداب معاشرت در فرهنگ حاکم بر منطقه خودمون، آداب معاشرت حاکم بر سایر مناطق هم یاد بگیریم. یکی از دلایلش هم شاید این که ممکنه روزی کار ریموت بهمون بخوره.
  • اخلاق کاری: اخلاق کاری، یه سری چارچوب ویژه خودش رو می‌تونه داشته باشه. اما خب هرشخصی میتونه چیزی بهش اضافه کنه یا تعریف مشخص‌تری ازش ارائه کنه. به نظرم لازمه که بعنوان برنامه‌نویس، اخلاق کاری خودمون رو هم شفاف مشخص کنیم.
  • روحیه کار تیمی: گفتن نداره، برنامه‌های بزرگ رو معمولا یک نفر نمی‌نویسه. اگر یک نفر هم بنویسه یحتمل بعدها به تیم محول کنه ادامه توسعه‌ش رو. پس لازمه که روحیه کار تیمی رو هم در خودمون تقویت کنیم.

اینا چیزایی بودن که در زمینه Soft Skill یا همون «مهارت نرم» به نظرم رسیدن. البته فقط اینا هم نیستند. اما بهتره اینها رو تا حد خوبی، تقویت کنیم.

یادگیری زبان انگلیسی

زبان انگلیسی، مدتهای زیادی (شاید از زمانی که امریکایی‌ها در دنیا اسم و رسم دار شدند؛ به طور دقیق از بعد جنگ دوم جهانی) میشه که شده زبان بین المللی. ارتباطات مختلف، تولید محتوا و حتی تولید علم به این زبان انجام میشه.

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

این دو موردی که در بالا اشاره کردم، خیلی با عنوان مطلب خوانایی نداشتند. راستش بهتره که بریم سراغ این که «چطور یک برنامه بنویسیم؟». حقیقتا این سوال، سوال خوبی نیست. به قول دوستی «سوالیه که مثل زلزله‌ست». البته اینطورام نیست، اما حقیقتش سوال خوب، سوالیه که هدف سوال‌کننده درش مشخص باشه.

پس بیایم اینطوری نگاه کنیم. شما شخصی هستید که شنیده برنامه‌نویس‌ها خوب پول درمیارن. یا شنیده که اگر مهارت برنامه‌نویسی هم داشته باشه، احتمالا بتونه آینده شغلی خودش رو بیش از حال؛ تضمین کنه. خب، این سوال که «چطور برنامه نویس بشم؟» یا «چطور برنامه بنویسم؟» و … مطمئنا تو ذهن شما می‌پیچه.

من بعنوان یک برنامه‌نویس، این سوال رو اصلاح می‌کنم به این شکل :

چطور یک برنامه تجاری بنویسم و آینده شغلی خودم رو تضمین کنم؟

الان این سوال از نظر من یک سوال خوبه. من میدونم شما چند هدف دارید :

  • برنامه نویسی
  • برنامه نویسی با هدف یک برنامه تجاری
  • تضمین آینده شغلی
  • (احتمالا) درآمد بالا

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

شناخت نیاز بازار

«نیاز بازار» چیزیه که احتمالا تو کار زیاد بشنویم. اما بیاید عمیق‌تر بهش فکر کنید. نیاز بازار دقیقا چیه؟ بازار از دو بخش عرضه‌کننده و تقاضاکننده تشکیل شده. تقاضاکننده یا مشتری؛ یک انسانه. یک شهروند مثل من و شما. پس شاید اولین و بهترین «نیاز بازار» نیازی باشه که من در حال حاضر دارم. منطقی‌تر بگم که اون چیزی که نیاز منه، مطمئنا نیاز تعداد زیادی آدم دیگه هم هست. این یعنی اگر این نیاز منحصر به شما بود، ممکن بود اصلا راه حل‌های احتمالی به سرتون نزنه.

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

طراحی راه‌حل

اول مقاله اشاره کردم که برنامه‌نویسی علیرغم این که در دنیای امروز حل یه سری مساله ریاضی نیست، اما ما همچنان به مدل‌سازی‌های ریاضیاتی برای طراحی یک برنامه خوب نیاز داریم. در واقع بعد از این که نیازهای بازار رو بسنجیم، نیاز داریم که تا حد امکان اونها رو ساده کنیم و از راه‌حل‌های ذهنیمون، مدل ریاضی بسازیم.

ساخت این مدل‌های ریاضی؛ نتیجه‌ش میشه الگوریتم‌های ما. نتیجه‌ش میشه دیتابیس‌های ما. پس یعنی بعد شناخت بازار، نیاز داریم تا حد زیادی ریاضی‌کاری کنیم و ببینیم که چی به چیه. تا برسیم به یه ساختاری که بتونه به برنامه تبدیل بشه.

چیدن پلن

این مرحله، خودش حتی شامل واحد‌های درسی میشه. نمی‌دونم عبارت «مهندسی نرم‌افزار» به گوش شما خورده یا نه؛ اما مهندسی نرم‌افزار، حرفش دقیقا همینه. یعنی شما وقتی یه چیزی داری و میخوای پیاده‌ش کنی، نیاز به پلن چیدن داری.

خب، فکر کنم اگر بخوام همینطوری توضیح بدم خیلی خیلی پیچیده و مصنوع میشه. بیایم موردی بررسی کنیم که یه پلن خوب چطوریه. در واقع چیزی که در ذیل این مطلب میاد؛ پلنیه که خودم برای یه پروژه چیدم (البته با کمی دخل و تصرف 🙂 )

  • معرفی اجمالی پروژه
  • بررسی پروژه های مشابه
  • طرح مساله
  • طرح راه حل
  • طرح ساختارهای داده‌ای
  • طرح ساختارهای الگوریتمی
  • طرح روش پیاده‌سازی
    • زبان، فرمورک و …
    • مدت زمان احتمالی پیاده سازی
    • امکاناتی که در فازهای مختلف نیاز داریم
    • پکیج‌ها و ابزارهای کمکی
  • توسعه‌پذیر کردن طرح پیاده شده
  • آماده‌سازی برای ارائه

با چیدن چنین پلنی، شما میتونید به خوبی روند توسعه رو پیش ببرید. ابزارهایی مثل ترلو و تسکولو و … هم هستند که بهتون کمک کنن در انجام دادن این مراحل.

پیاده‌سازی

فکر کنم اینجا دیگه میرسیم به خود خود خود برنامه‌نویسی. راستش این همه توضیح دادم که به اینجا برسیم. برای پیاده سازی، چی نیاز داریم؟

  • یه خط اینترنت
  • یه هدفون
  • یه پلی‌لیست از موزیک مورد نیاز برای برنامه‌نویسی (دیگه این بستگی به سلیقه‌تون داره 😉 )
  • مقدار خوبی ماده قندی و قهوه

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

اما برای پیاده سازی، ما ذهنیت نیاز داریم. راستش ذهنیت ما باید اینطوری باشه :

  • شناخت ابزار مناسب: ابزارهای زیادی همیشه دم دست ما هستند. اما این به خودمون برمی‌گرده که از کدوم استفاده کنیم برای انجام کارمون. نمی‌دونم شما دیدید یا نه. اما با چاقو میوه خوری هم میشه پیچ‌های ریز رو باز کرد. حالا سوال اینه، آیا کار منطقیه؟ نه! آچارهای ریز هستند که به طرفة‌العینی، پیچ رو برای ما باز میکنن. پس مهمه که ابزارها رو بررسی کنید و بهترین رو انتخاب کنید.
  • استفاده از ابزارهای کنترل سورس: خب، کنترل سورس، به شکل خوب و عجیبی؛ به تسریع روند توسعه کمک می‌کنه. اما مهم‌ترین بخشش که کمتر کسی بهش توجه می‌کنه اینه که این ابزارها، روند توسعه ما رو قابل ردگیری می‌کنند. یعنی چی؟ یعنی میشه فهمید سه روز پیش دقیقا چه حرکتی زدیم و آیا حرکتی که امروز می‌زنیم، درسته؟ و از این چیزا 🙂
  • تجدید نظر، هرجا که لازم بود : خب این آخرین مورد این لیسته. راستش دوست دارم با یه مثال جمعش کنم! کرنل لینوکس یه برنامه خیلی بزرگه که قریب به سی‌ساله داره توسعه داده میشه. توسعه اولیه این برنامه تا سال ۲۰۱۲ ادامه داشت. تقریبا بیست سال روی یک مدل پافشاری شده بود. اما می‌دونید اتفاق بد چی بود؟ این که در سال ۲۰۱۵ توسعه‌دهنده‌ها فهمیدن که یکم دیگه بگذره عملا هیچ غلطی نمی‌تونن بکنن (اگر با چنین لحنی می‌گم به این خاطره که دقیقا به همین وضعیت دچار شده بودند) و خب تصمیم گرفتن تو کل کرنل، تجدید نظر کلی کنن. این یعنی چی؟ یعنی نترسید و هرجا که دیدید دارید گند میزنید، حتی شده برگردید و از اول کار رو انجام بدید، این کار رو بکنید.

این هم موارد مورد نیاز برای پیاده سازی. خب یه نصیحت ریزی می‌کنم و بعدش هم کلا مطلب رو می‌بندم 🙂

بلندپروازی نکنید 🙂

رویاپرداز و بلندپرواز بودن خوبه. جف بزوس و بیل گیتس و ایلان ماسک و …، یه بخش بزرگی از موفقیتشون رو مدیون همین بلندپروازیشون هستند. اما بگذریم، بیش از اندازه بلندپرواز بودن هم گاهی کار دست آدم میده.

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

حرف آخر

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

آزاد و شاد باشید.

Share

ساختن یک API و چیزهایی که از آن یاد گرفتم

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

چه شد که این پروژه رو شروع کردم؟

حقیقتش شروع این پروژه به این دلیل بود که شدیدا دنبال ابزار مشابهی می‌گشتم. با این که بعد از این که این پروژه رو دپلوی کردم، یک دوستی در توییتر به من پیشنهاد استفاده از این ابزار رو داد؛ اما بهرحال من ابزار رو توسعه داده بودم و دپلوی هم کرده بودم.

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

مفهوم تازه : CORS

خب، وقتی که ما بکند و فرانتند پروژه رو از هم جدا می‌کنیم، در واقع داریم دوتا origin مختلف رو به هم وصل می‌کنیم. طبق استانداردهای وب؛ اصولا چنین کاری در مرورگرها؛ بخاطر مسائل امنیتی مجاز دونسته نشده. به همین خاطر، ما مفهوم تازه‌ای به اسم «چند ریشه‌ای» یا Cross-Origin رو خواهیم داشت.

حقیقتا وقتی فرانتند رو با جاوااسکریپت می‌نوشتم؛ دیدم که یک سری ارور بهم میده و توی اون ارورها بهم میگه که بکند من، برای «اشتراک گذاری منابع چندریشه‌ای» یا Cross-Origin Resource Sharing تهیه نشده. دوست داشتم از خود کد جاوااسکریپتم درستش کنم اما چون قرار بود روی هاست همین وبلاگ قرار بگیره و نه سرور مجزایی؛ ترجیح دادم که به جای node.js از وانیلا جی اس استفاده کنم (توضیح : وانیلا اصطلاحا به نرم افزار یا ابزار دست نخورده گفته میشه) و خب راهکاری براش پیدا نکردم (شاید هم چون درست دنبالش نگشتم) ولی از اونجایی که بکند رو با روبی و سیناترا نوشته بودم، براش راهکار پیدا کردم و این راهکار رو در یک ویرگول به اشتراک گذاشتم (لینک).

همین یک کار کوچک، باعث شد که من مفهوم کورز و صد البته نحوه کانفیگ درستش در بکند رو یاد بگیرم، از این جهت هم واقعا خوشحالم چرا که اکثر توسعه دهنده های فرانت، مدام از این قضیه که در بکند این مشکل حل نمیشه، نالانند ((:

چیزی که سالها عقبش انداخته بودم : زرین پال!

تقریبا از وقتی که فهمیدم اینترنت چیه، دنبال راهی برای کسب درآمد ازش بودم. فکر کنم دوم سوم دبیرستان بودم که سایت زرین پال به وجود اومد و اون موقع (چون به سن قانونی نرسیده بودم) نمی‌تونستم ازش استفاده کنم؛ یا این که باید از کسی میخواستم که قبول کنه به اسمش اکانت باز کنم (مثلا پدر یا مادرم).

از وقتی به سن قانونی رسیدم هم هرروز میخواستم برم و اکانت زرین پال درست کنم تا ازش برای حمایت و فروش و … روی اینترنت استفاده کنم. خلاصه که بالاخره همزمان با ریلیز این پروژه، این اتفاق هم افتاد ((: تازه دقیقتر بخواهیم حساب کنیم، برای این مساله هم مجبور شدم کارت بانکیم رو تمدید کنم و هم برای کارت هوشمند ملی اقدام کنم!

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

Share

مرگ وبلاگ نویسی، گشت و گذاری در سرویس های وبلاگ فارسی

شاید حدود ۱۰ سال پیش، وقتی به تازگی وارد ۱۲ سالگی شده بودم، شروع به ساخت وبلاگ در یکی از قدیمی ترین سرویس های وبلاگدهی فارسی، یعنی بلاگفا کردم. بلاگفایی که تا همین یکی دو سال پیش، به معنای واقعی از پرترافیک ترین وبسایت های فارسی به شمار میرفت.
دقیقا همان روزها، بلاگفا در صفحه اصلیش، دست کم دو تبلیغ نشان میداد، اخبارش و وبلاگ های بروز شده را لیست می‌کرد و گهگاه در شکل خبرهای فوری، امکانات حذف یا اضافه شده به سیستمش رو اطلاع رسانی می‌کرد. به این شکل مثلا فهمیدیم که مدتی blogfa.ir هم در دسترسه، و هر وبلاگی که شما بسازید هم در زیردامنه blogfa.com و هم blogfa.ir قرار میگیره.
البته، آن روزها پرشین بلاگ (قدیمی ترین سیستم بلاگدهی فارسی) و بلاگ اسکای و … هم رونق زیادی داشتند. در واقع، هرکس که میتونست هزینه های یک سرویس بلاگدهی (بخاطر سرور و منابع بالایی که نیاز داره و … ) رو تامین کنه و دانشی از برنامه نویسی وب داشت، یک سیستم بلاگدهی بالا میاورد. اما اونهایی که خیلی مطرح بودند، همین بلاگفا و بلاگ اسکای و پرشین بلاگ بودند.
دوستانی هم بودند که ترجیح میدادند – علیرغم فیلترینگ – از سرویس هایی مثل وردپرس یا بلاگر استفاده کنند، و ما هم با سختی و زحمت هایی که اون زمان برای عبور از سد داشتیم، وبلاگ ها رو میخوندیم و گهگداری هم اینتراکشنی داشتیم.

اما الان چه بلایی سر بلاگ ها اومده؟ امروز بعد از چند سال صفحه اصلی بلاگفا رو باز کردم! دیدم دیگه خبری از اخبار و لیست بلاگهای بروز شده نیست، همه‌ش شده لینک در صفحه اصلی، و صفحه اصلی صرفا شده یه محل برای لاگین کردن وبلاگ نویس ها!
لیست وبلاگ های بروز شده رو باز کردم و یکی دو تا وبلاگ رو خوندم، یکیشون دقیقا همین دهم آبان ویرایش شده بود و یکی هم حدود سه روز پیش. قبلا، این بروزرسانی ها، ساعتی بود. مثلا الان لیست رو میخوندیم، میدیدیم که در ۴ ساعت گذشته دست کم ۱۰ وبلاگ بروزرسانی شدند، اما الان این اختلافها به روز رسیدند!

گرچه، دلیل «مرگ وبلاگ نویسی» مشخصه، دیگه کسی نمیره از بلاگفا سرویس بگیره و بلاگ بنویسه، معمولا یه کانال تلگرامی میزنن و حرفاشون رو اونجا میزنن، دریغ از این که نمیدونن موندگار نیست، حداقل اونقدری که وبلاگ های روی بلاگفا هستند!

Share

#کارپینو، یا تاکسی نارنجی روی گوشی های هوشمند!

چند روز پیش، دوستی کارپینو رو به من معرفی کرد. رقیبی برای اسنپ و تپسی (و شاید استارتاپ های دیگر حوزه حمل و نقل درون/برون شهری ) که ظاهرا خود تاکسی رانی و شرکتهای تاکسی رانی خصوصی پشتش هستند، شما سفارش ماشین میدید و یک «تاکسی» میاد دنبالتون، یه چیزی مثل این 😀

IMG20145432

خب، این حرکت قشنگه ولی چند تا مشکل اساسیش تو چشم میزنه :

  • مسافر خودش باید دکمه «سوار شدم» رو بزنه، به نظر من احمقانه ترین چیزی که میتونه در چنین اپ هایی پیاده سازی بشه همینه! در واقع راننده هست که باید اعلام کنه مسافر سوار شده و سفر رسما آغاز شده، نه این که مسافر خودش اعلام کنه!
  • امکان امتیاز دهی به راننده وجود نداره، امروز عجله داشتم و راننده به موقع رسید، مسیر خوبی هم انتخاب کرد، ولی آخرش نشون داد به مبلغی که در اپلیکیشن وارد شده بی اعتنا بوده (در واقع ۹ هزار تومن بود و من ۱۰ تومن دادم، راننده پولی به من پس نداد تا خودم ازش خواستم که باقی پول رو پس بده) ، یعنی اگر اسنپ بود میشد ۴ از ۵ ستاره. من نتونستم بهش امتیاز مناسب بدم.
  • بعد از سوار شدن هیچ آپشن مسیریابی ای برای راننده فعال نشد، و راننده داشت از من مسیر میپرسید (البته انتهای راه). یکی از خوبی های اسنپ اینه که حداقل نیازی نیست در راه مسیر رو بگی و به کمک Waze (که البته الان جوابگو نیست!) و Google Maps و … ، خودش مسیر حدودی رو پیدا میکنه و فقط ممکنه در پیچ و خم ها و پس‌کوچه ها نیاز باشه که راهنمایی کنیم.
  • این برای من خیلی مهمه، عادت دارم که بعد از سوار شدن به اسنپ یا تپسی، پرداخت آنلاین انجام بدم و بنا به دلایلی تا جایی که بتونم از وجه نقد رد و بدل کردن در میرم! ولی این کارپینوی عزیز، هیچ آپشنی نداشت که بعد از سوار شدن بتونی پرداخت رو انجام بدی!
  • و آخرین مورد ، دقیقا همه پیام هایی که باید توسط راننده (موقع رسیدن، لغو سفر، … ) ارسال بشه امکانش هست که توسط مسافر ارسال بشه 😐 یعنی تغییری در محتوای پیام ندادند و همینطوری وارد اپلیکیشن شده!

گرچه، در وبسایتشون هم سوتی های خیلی عجیبی میشه پیدا کرد :

  • خیلی جاها اسم «ماکسی» به چشم میخوره، ظاهرا اسم اولی که برای استارتاپ (اگر بشه حتی اسمش رو استارتاپ گذاشت 😐 ) انتخاب کرده بودند ماکسی بوده، و بعد شده کارپینو. اما به خاطر عجله ای که برای لانچ کردن داشتند این مورد رو اصلاح نکردند.
  • وقتی روی آیکن Google Play کلیک کنید، به «کافه بازار» هدایت میشید! این هم چیزی بود که باعث تعجبم شد! با این که کافه بازار آیکن خاص خودش رو داره وبرای دانلود میشه ازش استفاده کرد ولی نمیدونم چرا اینجا از آیکن گوگل استفاده شده!

در کل، سرویس جالبیه ولی «خیلی خیلی خیلی» جای کار داره، خیلی از پیامها و محتوا باید عوض بشن، خیلی از آپشن ها باید اضافه بشن و از همه مهم تر این که باید برای مدیریت تراکنش ها و پرداخت ها سیستم خاصی پیاده سازی بشه که مشکلات برشمرده شده رو هم رفع کنه!

Share

پروژه گاه‌شمار

خب، من در گروه های تلگرامی این پیام رو میذاشتم :

دوستی مدتی پیش (که خیلی هم ازش نگذشته ) یک چالش رو بعنوان تمرین برنامه نویسی پیشنهاد داد، و اون هم نوشتن یک API بود برای دریافت ساعت و تاریخ.
من هم وارد این چالش شدم و یک API با روبی و سیناترا نوشتم، روی گیتهاب هم قرارش دادم ولی الان دپلویش کردم که اگر شما هم خواستید بتونید ازش استفاده کنید :
https://gahshomar-api.herokuapp.com/

خب، این هم پروژه ای بود که محسن بعنوان تمرین خواست که ما یه API بنویسیم، من هم این رو با Sinatra نوشتم و الان دپلوی شده و در دسترسه! امیدوارم ازش لذت ببرید 🙂

Share

قطعه کد «سلام دنیا» در زبان های مورد علاقه من – سری دوم

توی این مطلب یه تعداد از زبان های مورد علاقم رو معرفی کردم و درونشون قطعه کد سلام دنیا یا همون Hello World رو نوشتم. الان قصد دارم یه تعداد زبان دیگه رو معرفی کنم و این کد رو درون اون زبانها اجرا کنم. این زبانها هم جنبه فان دارن و در عین حال خیلی هم کاربردین.

۱. Arendelle :

این زبان، که سایتش از این آدرس  در دسترسه، ساخته دست دوست خوبم پویا کاری هست (اطلاعات شخصی ایشون توی وبسایت لینک شده). یک زبان برنامه نویسی فان برای کودکان که کلاینت آی او اس و آندروید هم داره.

کد   
'Hello, World'

۲. Apple Swift

زبان سوییفت اپل (نه اون سوییفتی که برای برنامه نویسی موازی و همروند استفاده میشه) به تازگی اوپن سورس شده و حقیقتا نتونستم تحمل کنم و نصبش کردم اون هم روی اوبونتو! و خب کار باهاش خیلی فانه (و به زودی هم یه سری مطلب در موردش میذارم) و البته اگر فرمورک های درست و حسابی تحت لینوکس هم براش ارائه شه، میشه گفت میتونه به یکی از بی رقیب ترین ها تبدیل شه!

کد   
print("Hello, World")

۳. Ada

خب، زبان Ada هم از زبانهایی بود که همیشه میخواستم یاد بگیرم، مدتها پیش در موردش خوندم و جالب ترین نکته این بود که اسم گذاریش از روی اولین برنامه نویس جهان بوده، پس مصمم شدم که حتما یکم باهاش بازی کنم 🙂

کد   
with Ada.Text_IO; use Ada.Text_IO:
procedure Hello is
 begin
  Put_Line("Hello, World");
 end Hello;

۴. Verilog HDL

این زبان هم برای شبیه سازی سخت افزار ازش استفاده میشه. شدیدا کاربردی و باحاله و میتونید کلی پروژه کول پیدا کنید که روی این زبان هستن، مثلا پیاده سازی اوپن سورس از پردازنده های مختلف مثل MIPS, x86, sparc و … .

کد   
module main;
 initial
  begin
   $display("Hello, World");
   $finish;
  end
endmodule

 

خب، این یکی مطلب کوتاه تر از نسخه قبلیش بود! اما یه نکته خیلی ریزی داشت، و اونم اینه که توی این چهارتا زبان میشه چهارتا طیف کاملا متفاوت رو دید. شما هم اگر پیشنهادی دارید دریغ نکنید و بذارید بدونیم 🙂

موفق باشید.

Share

رویای کریستالی برنامه نویسانه

خب، اول از همه بگم که نمیدونستم چه عنوانی رو باید انتخاب میکردم، و طبق فرمول «احمقانه ترین ایده ممکن» این عنوان رو روی پست گذاشتم. بگذریم، توی این پست میخوام یه پدیده جدید و خیلی خوب رو معرفی کنم. میدونید که من مدت زیادی هست که روبی کار شدم ( و حتی پایگاهی برای توسعه دهندگان روبی ایجاد کردم)  روبی زبان خیلی خوبیه ولی خب قاعدتا نمیشه به نیتیو کد تبدیلش کرد. همونطور که پایتون و … نمیشه نیتیو کد کامپایل کرد. اما با یه چیزی رو به رو شدم که دقیقا خود روبی بود، ولی نیتیو کد میشد. من که بهش سلام کردم، شما هم بهش سلام کنید. زبان برنامه نویسی کریستال یک زبان ruby – inspired هست که کاملا کامپایلری عمل میکنه. سینتکس کاملا سینتکس روبی هست و از این بابت خیالتون راحت باشه که اگر روبی بلدید، یاد گیری این زبان براتون چند دقیقه بیشتر زمان نخواهد برد. اجازه بدید چند مثال رو بررسی کنیم.

برنامه Hello World

کد   
puts "Hello, World"

 

چقدر فرق با روبی حس کردید؟ درسته! هیچ فرقی با روبی نداره. مثالهای بعدی هم هیچ فرقی ندارند.

برنامه شرطی (چک کردن سن قانونی)

کد   
if age >= 18
 puts "Legal"
else 
 puts "Not Legal"
end

 

استفاده از حلقه (برنامه چاپ اعداد ۰ تا ۱۰)

کد   
n = 0
while n <= 10
 puts n
 n += 1
end

 

برنامه شیء گرا (نوشتن کلاس Greeter )

کد   
class Greeter
 def initialize(name)
  @name = name
 end
 
 def say_hi
  puts "Hello, I am #{@name}"
 end
end

 

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

Share

مقدمه ای بر پرل

در پست قبلی سعی کردم تا حدودی با پرل، آشناتون کنم. در این پست هم قصد دارم تا حدودی بیسیک های پرل رو بررسی کنم. همونطور که در پست قبلی اشاره کردم، پرل شباهت بسیار زیادی به C داره، البته این شباهت به php بیشتره تا C ، ولی خب معمولا بیان میشه که پرل سینتکس مشابه C داره. شما چه C بدونید و چه php ، کد زدن با پرل براتون بسیار راحت میشه. خب، بذارید از اول اول شروع کنیم، یعنی نصب و راه اندازی پرل روی یه سیستم لینوکسی، باید بگم که پرل معمولا روی توزیع های آماده (مثل اوبونتو) نصب شده، چرا که بخش عظیمی از کانفیگ فایلها، توسط اسکریپت های پرل انجام میشه. ولی روی توزیع هایی که آماده نیستند (مثل آرچ، جنتو و …) معمولا نصب نیست (ولی با نصب X نصب میشه و خیالتون از این بابت راحت باشه). حالا که خیالتون راحت شد که پرل رو دارید ( 😀 ) ، بیاید مثل دو پست قبلی، به دنیا سلام کنید. برای این کار، یه فایل به اسم hello.pl ایجاد کنید و داخلش بنویسید :

کد   
print "Hello, World!\n";

خب حالا بخوایم این کد رو آنالیز کنیم، print که مشخصه کارش چیه، یک رشته متنی رو چاپ میکنه که روبروش هم ما از ” استفاده کردیم، و یک متن نوشتیم. اون کرکتر بک اسلش هم یک خط جدید برامون ایجاد میکنه. اما میشه این رو طور دیگه هم نوشت. در واقع میتونید متن Hello, World رو درون یک متغیر بریزید و متغیر رو چاپ کنید!

کد   
$hello = "Hello, World";
 
print "$hello\n";

خب، از این کد میشه به شباهت زیاد پرل با php هم پی برد، پرل هرچیزی که با $ شروع بشه رو خودکار متغیر در نظر میگیره. خب انواع متغیر در پرل مثل سایر زبان ها، به عدد صحیح و ممیز شناور و … تقسیم میشه . در واقع در کد زیر مشخص میشه که این کد ها چی هستند :

کد   
$int = 1;
$float = 3.14;
$char = 'a';
$string = 'Hello, World';

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

Share

ملاقات با اوبونتو ۱۵.۰۴

Screenshot from 2015-04-24 16:09:07پنجشنه، نسخه جدید اوبونتو، یعنی ۱۵.۰۴ منتشر شد. این نسخه، اولین نسخه منتشر شده در سال ۲۰۱۵ و در ماه آپریل، یعنی ماه چهارم هست و طبیعتا بخاطر همین نامش میشه ۱۵.۰۴ . در این تاپیک قصد بررسی فنی ندارم، فقط تنها خوبیش برام این بود که مینت مزاحم رو پاک کردم و این رو جاش نصب کردم. نسخه بعدی، ۶ ماه دیگه یعنی در ماه ۱۰ میلادی منتشر میشه. هنوز جزئیاتی ازش منتشر نشده. در مورد این نسخه بخوام بگم (۱۵.۰۴) باید بگم که در یک کلام «عالی» بود. تقریبا همه نسخه هایی که روی لپتاپی که یک سال از عمرش میگذره نصب کردم، خیلی خیلی خوب جواب دادن. تست ها و Review های دیگر هم همینو میگن :).

نرم افزار پخش ویدئوی این نسخه هم ظاهر جالبی پیدا کرده :

Screenshot from 2015-04-25 01:24:41تقریبا این نرم افزار رو ظاهرش  رو به مینیمالیست ترین شکل ممکن باز-طراحی کردن (بابت عکس ترسناکش معذرت! این کنسرت تنها ویدئوی موجود بود اون موقع که داشتم تست میکردم نرم افزارها رو!).

خلاصه که تغییرات زیادی کرده این نسخه و در یک مطلب طولانی، در موردش بیشتر خواهم نوشت 🙂

Share