در شرکتتان برنامه‌ساز نیاز دارید، نه برنامه‌نویس

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

در شرکتتان برنامه‌ساز نیاز دارید، نه برنامه‌نویس

موقعیت بسیار مهم است. پند یک مدیر ممکن است بی‌ارزش یا بدتر باشند اگر مناسب وضعیت شما نباشد. تصمیمی درست برای شرکتی بزرگ ممکن است برای کوچک‌تر کشنده باشد. پیش از آنکه پیشنهاد‌های مدیریتی هرکسی از جمله من را بشنوید‍ ☺، مطمئن شوید که موقعیت خودتان را مدنظر دارید.
من یک شرکت نرم‌افزاری کوچک را می‌گردانم بدون هیچ کمک مالی بیرونی. شرکت ما (SourceGear) حدود ۶ سال سن و ۲۵ کارمند (در زمان نوشته شدن این مقاله: سال ۲۰۰۳) دارد.

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

در این مقاله منظور از برنامه‌نویس (Programmer) فردی است که کاری جز نوشتن کُدهای نو و (اگر خوش‌شانس باشید) اشکال‌زدایی، نمی‌کند. او مشخصه‌ها(Specifications) را نمی‌نویسد. او تست‌کیس‌های خودکار را نمی‌نویسد. کمکی برای اینکه سیستم ساخت خودکار بروز باشد، نمی‌کند. به مشتریان کمک نمی‌کند تا مشکلات جدی‌شان را حل کنند. در نوشتن مستندات کمک نمی‌کند. او حتا کُد را هم نمی‌خواند. تنها کاری که او می‌کند نوشتن کد جدید است.

در شرکت‌های کوچک نرم‌افزاری شما یک چنین آدم‌هایی را نمی‌خواهید.

به‌جای برنامه‌نویسان (کسانی متخصص نوشتن کد هستند) آنچه شما نیاز دارید برنامه‌سازان (Developer) هستند (کسانیکه به روش‌های مختلف تلاش می‌کنند تا محصولی موفق ساخته شود).

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

~~~

حدود (وظایف و اختیارات) در برابر انعطاف‌پذیری

این تفاوت‌ به‌راستی مهم بین شرکت‌های کوچک و بزرگ است:

  • در شرکت کوچک بیشتر افراد نقش‌های مختلف دارند. امکان‌پذیر نیست که فردی داشته‌باشید که تنها روی یک زمینه تمرکز می‌کند. شرکت‌های کوچک افراد همه‌فن‌حریف‌ی را نیاز دارند که به شرکت اهمیت می‌دهند و برای هرکاری که به شرکت کمک کند، پیش‌قدم می شوند. حسابدار یا کتابدار هرکاری را سر-و-سامان می‌دهند. معمولا کسانی وجود دارند که همه کارها را انجام می‌دهند و سرشان همیشه شلوغ است و هیچ‌کس هم نمی‌داند که آنها چه می‌کنند. در اینجا مفهوم کلیدی انعطاف‌پذیری است.
  • شرکت شرکت‌های بزرگ متخصصان بیشتری دارند. دستمزدها با «حساب‌های دریافتنی» فرق‌ می‌کند که آن‌هم از «حساب‌های پرداختنی» جداست. معماران نرم‌افزار، طراحی می‌کنند. برنامه‌نویسان کُد می‌نویسند. مدیران فنی برنامه‌نویسان را مدیریت می‌کنند. مدیران پروژه (برنامه) ها مشخصه و زمانبندی را پیگیری می‌کنند. مدیران محصول جایگاه‌سازی و پیام‌رسانی می‌کنند. مبلغان، خوب، کسی به راستی نمی‌داند که آنها چه می‌کنند.☺ به هرحال هرکسی کاری مشخص و تعریف‌شده دارد. مفهوم کلیدی اینجا احترام به حدود (وظایف و اختیارات) است.

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

~~~

برنامه‌سازان

در شرکت کوچک نرم‌افزاری هر برنامه‌سازی پیش و بیش از هر چیز برنامه‌نویس است. بخش اصلی وقتش باید صرف نوشتن کُد و اشکال‌زدایی گردد. اما نیاز است که برنامه‌سازان در دیگر زمینه‌ها هم کمک کنند، زمینه‌هایی چون:

  • مستندات مشخصه‌ها
  • مدیریت پیکربندی
  • بازبینی کُد
  • تست کردن
  • تست‌های خودکار
  • مستندسازی
  • حل مشکلات جدی مشتریان

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

زمانیکه تیم برنامه‌نویسان شما به مرور برنامه‌ساز می‌شوند، شاید سلسله مراتب کاری شما تغییر کند. ممکن است که بهترین برنامه‌ساز شما همان کسی نباشد که مشکلات به‌راستی سخت را برطرف می‌سازد. یک برنامه‌نویس با استعداد فراوان می‌تواند برنامه‌سازی بسیار بد باشد.کُدنویسی بخشی لازم اما ناکافی برای برنامه‌ساز بودن است. همینگونه، افراد با استعداد کمتر در تیم شما هنوز می‌توانند خودشان را به عنوان برنامه‌سازانی عالی نشان دهند با مشارکتی که در بخش‌های غیرکُد نویسی محصول می‌کنند.

~~~

پرسشهای پُربسامد (متداول)

می‌توانیم برنامه‌نویسانِ خود را فقط به کُدنویسی بگماریم و برای همه دیگر کارها گروهی دیگر را بکاربگیریم؟

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

برنامه‌نویسان ما نمی‌دانند که چگونه همه این کارهای دیگر را انجام‌دهند؟

راستی؟ مطمئن هستم که دانشکده‌های کامپیوتر ابزارهای مدیریت زنجیره تامین (SCM) و مهارت‌های پشتیبانی فنی را درس می‌دهند، درست؟☺

گرچه دانشکده من این چیزها را یاد نمی‌داد. روشن است که برنامه‌نویسان شما نمی‌دانند که چگونه جنبه‌های جز-کُدنویسی ساخت محصول را انجام‌ دهند. به آنها آموزش دهید.

آموزش رسمی ممکن است نقشی ایفا کند، اما بهترین یادگیری از تجربه می‌آید. برنامه‌سازان شما باید پند شرکت نایکی (Nike) «انجامش بده» را بکار بندید. مطمئن شوید که آنها فرصت اشتباه داده‌اید. به آنها اجازه دهید از اشتباهاتشان یادگیرند.

برنامه‌نویسان ما نمی‌خواهند همه این کارها را انجام دهند

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

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

آیا یافتن برنامه‌سازی که مهارت‌هایی اینچنین گوناگون دارد، سخت نیست؟

بله هست. برنامه‌سازان واقعی و راستین ارزشمند هستند. احتمالا شما نمی‌توانید آنها را از بیرون بکارگیرید. مجبور هستید که به برنامه‌نویسان کمک کنید که برنامه‌ساز شوند.

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

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

بله، این مساله‌ای است. از این فرصت بهره می‌جویم تا از اصل اریک (خودم) در مدیریت نرم‌افزار یاد کنم:

نمی‌توانید مسایل را حذف کنید،
اما می‌توانید بده-بستانی انجام‌دهید
مسایلی که هم‌اکنون دارید را بدهید
در برابر آنها مسایلی را که ترجیح می‌دهید، بستانید.

برنامه‌سازان وقت آزاد بیشتری نیاز دارند وگرنه هیچ کُدی نخواهند نوشت. خوب این مساله‌ای است که ترجیح دارد برمسایلی که برایتان پیش خواهد آمد هنگامی‌که با افرادی با چشم‌انداز باریکِ «تنها کُد» سروکار پیدا می‌کنید. تلاش کنید زمان خود را ساماندهی کنید. برای نمونه در یک روز همزمان کُدنویسی و پشتیبانی فنی را انجام‌ ندهید.

پس شما می‌گویید که برنامه‌سازان ما مجبورند همه دیگر کارها را انجم دهند؟

خیر. بهتر این است که برنامه‌سازان هنوز بیشتر(اما نه همه) وقتشان را صرف نوشتن کُد کنند. اگر بودجه شما اجازه می‌دهد دسته‌های گوناگونی از متخصصان هستند که می‌توانید بکار بگیرید:

پشتیبانی فنی «سطح یک»

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

تستِ دستی، بازبینی اشکال‌زدایی و …

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

مستندسازی

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

مدیر سیستم (System Administration)

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

این نوشته برگردانی است از:

Sink, Eric. “Small ISVs: You need Developers, not Programmers

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

Balatarinاین نوشته را به بالاترین بفرستید:

راز موفقیت

“قربان! راز موفقیت شما چیست؟”

“دو واژه”

“خوب، آن دو واژه چه هستند؟”

“تصمیم‌های درست”

“حال شما چگونه تصمیم‌های درست می‌گیرید؟”

“یک واژه”

“آن چیست؟”

“تجربه”

“شما چگونه تجربه می‌اندوزید؟”

“دو واژه”

“آنها چه هستند قربان؟”

“تصمیم‌های نادرست”

اصل این نوشته را از از اینجا آورده‌ام

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

نظریه بازی‌ها – راه برنده شدن

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

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

درس‌هایی در نظریه بازی‌ها و طراحی مکانیسم

آنچه درپی می‌‌آید فهرستی از پیوند‌ها به صفحه‌های وب درس‌های ارایه شده در دانشکده‌های کامپیوتر معتبرترین دانشگاه‌های جهان درباره “نظریه بازی‌ها” و “طراحی مکانیسم” است:

۱٫ Asu E. Ozdaglar’s Game Theory with Engineering Applications
۲٫ David C. Parkes’s Computational Mechanism Design
۳٫ Noam Nisan’s Course on CS, Game Theory, and Economics
۴٫ Christos Papadimitriou’s Course on Algorithmic Aspects of Game Theory
۵٫ Joan Feigenbaum’s Course on Economics and Computation
۶٫ Jeff MacKie-Mason’s Course on Information Economics
۷٫ Amy Greenwald’s Course on Agent-Based Economics
۸٫ Yoav Shoham’s Multi-Agent Systems Course
۹٫ Subhash Suri’s Course on Computation and Market Mechanisms
۱۰٫ Tuomas Sandholm’s Course on Foundations of Electronic Marketplaces
۱۱٫ Peter Cole’s and Al Roth’s Market Design Course
۱۲٫ Kate Larson’s Electronic Market Design Course

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

جدول تکاملی نام‌تجاری

این جدول بسیار جالب را ببینید، به مانند جدول “جدول تناوبی عناصر” درست شده و واژگان بنیادین بازاریابی و کسب و کار در آن شرح‌داده شده. موس را بر روی هر عنصر بگیرید تا توضیح را ببینید.

branding definitions

نظریه‌ی الگوریتمی بازی‌ها

یکی از گرایش‌های نو در کامپیوتر “نظریه‌ی الگوریتمی بازی‌ها” یا Algorithmic Game Theory است. این گرایش که به تازگی طرفداران زیادی هم پیدا کرده یکی از فصل های مشترک کامپیوتر و اقتصاد است و همانگونه که از نامش بر می‌‌آید به جنبه‌های الگوریتمی نظریه‌ بازی‌ها، مکانیسم‌های طراحی شبکه، اقتصاد و طراحی مکانیسم‌ها می‌پردازد و یکی از پرکاربردترین زمینه‌های کامپیوتر است.

برایم جالب بود که یکی از کسانی که در این زمینه کار می‌کند یک ایرانی است: سید وهاب میررکنی مهندسی کامپیوتر خود را از شریف گرفته و دکترا و فوق‌دکترایش را از MIT، وی همچنین برای مایکروسافت و IBM کارکرده است.

هر روز که می‌گذرد جنبه‌های مشترک بیشتری بین کامپیوتر و اقتصاد می‌یابم، برای نمونه “فون نویمان” که ما کامپیوتری‌ها او را از بنیان‌گذاران و نظریه‌پردازان کامپیوتر‌های امروزی می‌دانیم و هنوز هم معماری‌ کامپیوتر‌هایی را که بکار می‌بریم “معماری فون‌ نویمانی” می گوییم، از پایه‌گذاران نظریه بازی‌ها است.

راستی کسانی که می‌خواهند با نظریه بازی‌ها آشنا شوند، نخست فیلم “ذهن زیبا” (A Beautiful Mind) که به فارسی هم دوبله شده است را ببینند، این فیلم بسیار زیبا شرح زندگی “جان نش” ریاضی دان بزرگ است که به خاطر کارهای درخشانش در نظریه بازی‌ها، جایزه نوبل اقتصاد سال ۹۴ را برد. نظریه‌ای بسیار جالب است که در اقتصاد،علوم سیاسی و استراتژیک، مذاکره، مدیریت و کامپیوتر کاربرد فراوان دارد و اگر اشتباه نکنم تا به حال جابزه نوبل را نصیب ۷ نفر کرده است، از جمله امسال که جایزه نوبل به خاطر “طراحی مکانیسم‌ها” -یکی از شاخه‌های نظریه‌ی بازی‌ها- نصیب ۳ نفر گردید. (پست “چه کسانی اقتصاد را دوست دارند و چه کسانی ندارند!!؟؟” را ببینید.)

تمام کسانی که بر روی “نظریه‌ی الگوریتمی بازی‌ها” کار می‌کنند کامپیوتری هستند و زمینه خوبی برای کار و پژوهش به ویژه در کارشناسی‌ارشد و دکترا است.

به تازگی (یک ماه پیش) کتابی با همین نام “Algorithmic Game Theory ” توسط انتشارات دانشگاه کمبریج چاپ شده که نسخه‌ای از آن از اینجا قابل دریافت است و برای کسانی که می‌خواهند در این باره بیشتر بدانند، بسیار عالی است.

همینطور اگر خواستید درباره چهار نویسنده (ویراستار) کتاب، زمینه‌های پژوهشی و درس‌هایی که ارایه می‌کنند بیشتر بدانید:

Vijay V. Vazirani
Tim Roughgarden
Éva Tardos
Noam Nisan

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

فایر‌فاکس + پارسی: ارمغانی از آسمان

من فایرفاکس را بسیار دوست دارم، مدت‌ها پیش از آنکه نسخه ۱٫۰ آن بیرون بیاید آن را نصب کردم و درجا دلبسته آن شدم. حتا نامش را دوست دارم و هنگامیکه نامش در دبیان و پیرو آن در پارسیکس تغییر کرد بسیار ناراحت شدم.

از دیگر اخلاق من این است که به شدت از نرم‌افزارهای فارسی شده دوری می‌کنم. وقتی نخستین بار درباره افزونه یا همان “ترجمه فارسی فایرفاکس” خواندم، با تردید و از روی کنجکاوی آنرا نصب کردم. اما چیز دیگری بود، از آن لذت بردم و بکار بردن آن‌را توصیه می‌کنم:

۱٫ نخست اینکه این کار علمی و رسمی صورت‌گرفته بود و افزونه از سایت رسمی بنیاد موزیلا دریافت می‌شد و آنها این افزونه را آزموده و تایید کرده بودند.

۲٫ نصب بسیار بسیار آسان بود، تنها کافی بود تا روی دکمه “Install Now ” کلیک کنی تا برنامه نصب گردد. (در نسخه های پیشین نصب Quick Locale Switcher هم لازم بود- البته به همان سادگی- اما در نسخه ۲٫۰٫۰٫۸ این کار هم لازم نیست) آموزش نصب را اینجا می‌توانید ببینید.

۳٫ این کار را شیر مردی به نام “بهرام مراوندی” به تنهایی انجام داده بود، مهندسی ایرانی که برون از ایران کار می‌کند و این کار را از روی علاقه انجام داده بود. (راستی براساس آخرین اطلاعات آقای مراوندی اصفهانی است)

۴٫ از دیگر مزایای این ترجمه این بود که با بروزشدن‌های فایرفاکس بروزمی شد.

این پروژه ادامه پیدا کرد تا امروز که گسترش پیدا کرده و افزونه های دیگری نیز پارسی شده و می‌شود.

به‌تازگی سایتی جدا (http://www.mozillafirefox.ir) برای پروژه فایر فارسی راه‌اندازی شده است، سایتی شکیل به همراه راهنماها و آموزش هایی کاربردی به فارسی. که آقای مراوندی به تنهایی آن را راه اندازی کرده و نگهداری می کند.

این سایت دارای بخشهای مختلف از جمله برنامه‌نویسی، بلاگ، افزونه‌ها و راهنما است. صفحه‌اصلی آخرین اخبار مرتبط با فایرفاکس و پروژه را دربردارد.http://www.mozillafirefox.ir/

راهنمای آن عالی است و همه چیز را برای تبدیل یک فرد به یک کاربر حرفه‌ای داراست، از مدیریت کوکی‌ها گرفته تا فهرست کلیدهای میان‌بر فایرفاکس.

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

بلاگ خوبی هم دارد که خودم در Google Reader عضو شدم تا با آن هماهنگ باشم.

بخش برنامه نویسی هم به کار کسانی می‌آید که می‌خواهند برای فایرفاکس برنامه‌نویسی کنند و بخش زیبایی است.

اما این تصویری که در کنار می‌بینید، نواری است که در کنار سایت قرار دارد و حاوی پیوند به مهمترین نوشته‌های سایت است (دست‌کم از دید من): “برنامه نویسی اولین افزونه”: در ۳ قسمت، راهنمایی است برای نوشتن افزونه‌های دلخواه برای فایر فاکس، “شرح کامل about:config” راهنمای کامل شخصی‌سازی و پیکربندی دلخواه آن ووو…. حتما سایت را ببنید و آنرا پیگیری نمایید.

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

پ.ن: در پست “چرا دانشجویان ایرانی باید در پروژه های آزاد/بازمتن مشارکت کنند!؟” به دانشجویان توصیه کردم که به دلایلی- که آنجا آورده ام- درپروژه‌های آزاد/بازمتن مشارکت کنند. یکی از پروژه‌های مفید و کاربردی که دانش برنامه‌نویسی زیادی هم لازم ندارد، این پروژه است: بشتابید.

برنامه‌سازی- برنامه‌نویسی

تلاش می‌کنم از این پس به‌جای “توسعه” در برابر Developing برابرنهاد “برنامه‌سازی” را بکاربرم. و “برنامه‌نویسی” را برای Programming. در نتیجه “برنامه‌نویس” برای Programmer و برنامه‌ساز برای Developer.

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

آنگاه می‌توان به‌جای “محیط مجتمع توسعه” برای IDE، “محیط مجتمع برنامه‌سازی” یا زیباتر از آن “محیط یکپارچه برنامه‌سازی” را بکاربرد که مفهوم را کامل می رساند. راستش این “محیط مجتمع توسعه”هیچ حسی در من ایجاد نمی‌کند. حتا می‌توان با کمی گذشت دربرابر زیباسازی “ بستر یکپارچه برنامه‌سازی را بکار برد. واژه بستر یکی از پیشنهاد‌های داریوش‌ آشوری است.

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

پ.ن: گفتم حالا که آنها را گفتم این را نیز یگویم: از دیگر واژگان بسیارپرکاربردی که بیشتر جاها نادرست نوشته می‌شود “فناوری” است که نادرست “فن آوری” یا “فنآوری” نوشته می‌شود. این واژه برابرنهادی است برای Technology ور در فارسی ترکیبی است از فن + وری است، آن الف هم که آن میان آمده صورت ساز یا formative (از اصطلاحات زبانشناسی) است، نمونه‌های دیگری نیز از این دست در فارسی داریم: جنگ + ور–> جنگاور، دل + ور–> دلاور، پس + مدرن –> پسامدرن.

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

مدیران عامل شرکت های آزاد/باز‌متن: آشنایی، تجربه‌ها و توصیه‌ها

یکی از معروف ترین بلاگ ها درباره کسب و کار باز متن The Open Road است که در پست “بلاگ هایی برای پیدا کردن دید بهتر از بازمتن” هم از آن نام بردم، این بلاگ را Matt Asay یکی از بهترین تحلیل گران کسب و کارهای آزاد/بازمتن می نویسد که خود در شرکت بازمتن Alfresco هم کار می کند. دراین بلاگ او یک سری نوشته دارد با نام “مدیر عامل باز متن” که اکنون به شماره ۲۲ رسیده است و در این نوشته ها او درباره موفق ترین مدیران عامل شرکت های آزاد/بازمتن، شرکتشان و توصیه‌های آنها می‌نویسد، پیشتر در مقاله “۱۲ مدل کسب و کار بازمتن” مدل کسب‌ و کار برخی از این شرکت ها را بیان کرده‌ام. خواندن این نوشته ها را به کسانی که در فکر برپایی شرکتی آزاد/بازمتن هستند و یا یک چنین شرکتی را اداره می‌کنند اکیدا توصیه می‌کنم.

اینجا نام هر فرد، سپس شرکتی که وی مدیر عامل آن است آورده شده:

The Open Source CEO Series:

۱٫ Dave Rosenberg, MuleSource
۲٫ Javier Soltero, Hyperic
۳٫ Marten Mickos, MySQL
۴٫ John Powell, Alfresco
۵٫ Fabrizio Capobianco, Funambol
۶٫ Boris Kraft, Magnolia
۷٫ Kelly Herrell, Vyatta
۸٫ Satish Dharmaraj, Zimbra
۹٫ Ranga Rangachari, Groundwork
۱۰٫ Dries Buytaert, Drupal
۱۱٫ John Roberts, SugarCRM
۱۲٫ Toby Oliver, Path Intelligence
۱۳٫ Danny Windham, Digium
۱۴٫ Bill Karpovich, Zenoss
۱۵٫ Mark Brewer, Covalent
۱۶٫ Gianugo Rabellino, Sourcesense
۱۷٫ Bob Walters, Untangle
۱۸٫ Paul Doscher, JasperSoft
۱۹٫ Pete Childers, Zmanda
۲۰٫ Rod Johnson, Interface 21
۲۱٫ Harold Goldberg, Zend Technologies
۲۲٫ Eero Teerikorpi, Continuent

اگر می خواهید بار دیگری که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید.

چرا دانشجویان ایرانی باید در پروژه های آزاد/بازمتن مشارکت کنند!؟

می دانید که من از طرفداران نرم افزارهای آزاد/بازمتن هستم، اما این پست ربطی به این طرفداری ندارد. حتا اگر می خواهید پس از فراغت از تحصیل به خارج رفته و در مایکروسافت! استخدام شوید مهارت هایی که در این پروژه ها فرا می گیرید بسیار به استخدام راحت و سریع تر شما کمک می کند.

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

شرکت در پروژه های آزاد/باز متن چه کمکی می کند؟

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

– کُِد خوب بنویسید و این کار را تمرین کنید، دیگر اعضای گروه (تیم) کد های شما را درست می کنند و به شما می گویند که چگونه کد بهتری بنویسید. در ضمن هرچه بیشتر کُد بنویسد، ماهرتر می شوید: کارنیکو کردن از پر کردن است.

– با استاندارد ها و روش های به روز و کاربردی برنامه نویسی آشنا می شوید .

– چون پروژه بین المللی است -و ما معمولا تا اجبار و زور بالای سرمان نباشد کاری را نمی کنیم- زبانتان را تقویت می کنید.

– با نرم افزار های و روش های کنترل نسخه (Version Control) آشنا می شوید.

– کار گروهی یاد می گیرید. (امیدروارم!)

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

پ. ن. ۰: در ادامه می‌توانید «راهنمای کوچک همکاری در پروژه‌های بازمتن» را بخوانید.

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

پ.ن. ۲: این پی‌نوشت را ۸ ماه پس از پست می‌نویسم. نوشته «هفت دلیل برای‌ برنامه‌نویسی با لینوکس»  از مجله شبکه
را بخوانید.

پ.ن ۳: همچنین نوشته‌ی مفید سعید زبردست با نام «همکاری در پروژه های کد باز بدون کد نویسی» را بخوانید.

اگر می خواهید بار دیگر که  مطلبی نوشته شد، آگاه گردید. عضو خوراک (feed) این بلاگ شوید(فید چیست و نحوه استفاده از فید.) همچنین می توانید مرا در تویتر دنبال کنید. «فهرست همه نوشته‌ها»ی من را اینجا ببینید.

Balatarinاین نوشته را به بالاترین بفرستید: