Softwaring

سایت Harvard Business Review چند روز پیش مطلبی را منتشر کرده که 12 مشخصه یک مکان ایده آل برای کار را برشمرده است. این مطلب بر اساس بیش از 100 مطالعه صورت گرفته تنظیم شده است.

به قول نویسنده - Tony Schwartz  - در صورتی که شرکتی این شرایط را فراهم کند، کارکنان حداکثر رضایت شغلی ممکن را خواهند داشت و در نتیجه بیشترین بهره وری و وفاداری به سازمان حاصل خواهد شد.

بر اساس این مطالعه در سرتاسر جهان تنها 20% افراد از محیط کار خود ابراز رضایت کامل کرده اند.

1.       پرداخت دستمزد کافی که شخص بتواند در حوزه استاندارهای خود زندگی کند.

2.       شریک کردن مالی کارکنان در موفقیتهای کسب شده برای سازمان نظیر سهامدار کردن کارکنان، پرداخت پاداش متناسب با کارایی و بهره وری و از این دست.

3.       طراحی محیط کاری به شکلی که محل امن، راحت و لذت بخشی برای کارکنان به وجود آورد، محیطی که امکان تعامل و فعالیتهای اجتماعی را فراهم کرده و در عین حال به اندازه کافی به شخص حس خصوصی بودن فضای اطراف خود را بدهد.

4.       فراهم کردن مواد غذایی سالم و با کیفیت با کمترین هزینه ممکن.

5.       ایجاد امکاناتی برای استراحت و کسب انرژی مجدد و ترغیب کارکنان به استفاده از این امکانات. در حالت ایده آل ایجاد محیطی برای چرت در میان روز برای کسب انرژی مجدد برای ساعتهای بعد از ظهر.

6.       ایجاد امکانات ورزشی و فعالیتهای بدنی برای کارکنان و ترغیب آنان برای استفاده حتی در میان روز.

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

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

9.       ملزم کردن مدیران و راهبران سازمان به احترام و دلسوزی نسبت به زیردستان.

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

11.   ایجاد شرایطی برای آموزش، مطالعه و پیشرفت کارکنان در زمینه های مرتبط با حرفه و حتی مهارتهای درونی و شخصی.

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

مطلب کامل:

http://blogs.hbr.org/schwartz/2011/09/the-twelve-attributes-of-a-tru.html

16 Solution Architect Anti-patterns

by John Spacey

A few common anti-patterns that every solution architect should know.

1. Re-inventing the wheel - Needlessly engineering a proprietary solution to a problem that already has a standard solution.

Example: Building your own web server.

2. Technology Proliferation - Needlessly increasing the complexity of the technology stack.

Example:The organization uses three web server products and you introduce another.

3.Over Engineering - Building complex functionality when a simple solution would suffice.

Example: Introducing a complex workflow product to handle simple approvals.

4. Under Engineering - When the architecture can not support the business requirements.

Example: A solution that can not support business volumes (performance requirements).

5. Stubborn Silo - Refusing to use common solutions without a good reason.

Example: Building point to point integrations instead of using the enterprise ESB.

6. Bleeding Edge - Using the latest hype technology before all the bugs have been worked out.

Example: Expensive hardware that is marginally faster than slightly older models.

7. Silver Bullet - When architects use a single technology for all projects.

Example: Using SOA for everything — even when there is zero chance of service reuse.

8. Ivory Tower - A highbrow or ascetically pleasing design that is not practical.

Example: Spending excessive time designing a elaborate solution to a simple problem.

9. Garden in the Desert - Building a solution on the wrong platform.

Example: Building a complex business application with office productivity software.

10. Vendor Lock-in - Building too much functionality on a proprietary platform.

Example: Using one large vendor for all your systems.

11. Gold Plating - Adding bells and whistles to a system that don't add value.

Example: Optimizing a mobile website for devices that few of your customers own.

12. Politics Oriented Architecture - Allowing office politics to interfere with design decisions.

Example: The CRM has the data you need but your boss has a bad relationship with the CRM team — so you get the data from some downstream system that has stale data.

13. Path Of Least Resistance - A lazy architecture that fails to plan for change — choosing the cheapest implementation.

Example: Choosing point to point integration over ESB because it is easier.

14. Over the Head - Ignoring requirements that the architect fails to understand — assuming they have no impact.

Example: Business requirements specify compliance with a set of regulations — architects ignore the requirement because they don't understand it.

15.Perception Mismanagement - When the solution architect makes promises and then can't deliver.

Example: Promising real time calculations that are almost impossible to calculate in real time.

16. Pattern Happy - Overuse of patterns.

Example: Designs that have factories that do nothing.

فردا 15 نفر مهمان دارید و می خواهید برای آنها غذایی را آماده کنید که برای اولین بار می خواهید پخت آن را تجربه کنید. فرض کنید خورش فسنجان

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

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

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

هر چند این رویکرد زمان بیشتری طلب می کند اما ریسک پخت غذای اصلی به میزان قابل توجهی کمتر بوده و نتیجه نهایی بسیار قابل پیش بینی تر و نزدیکتر به آنچه مطلوب است خواهد بود.

زیاد دیده ام هزینه های – گاهی بسیار گزاف – تحمیل شده به مهاجران به علت عدم آشنایی با محیط، فرهنگ و شرایط اقامتگاه جدید.

چند بار این هزینه ها به خود من هم تحمیل شده و در بیشتر موارد علت چیزی نبوده جز عدم آشنایی و تقریبا در همه موارد قابل پیشگیری.

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

یک - هنگام خرید اتوموبیل، آنرا بیمه شخص ثالث کردم، بدون اینکه شرایط بیمه را – که دفترچه ای قطور بود – به دقت بخوانم. چند ماه بعد همسر تصادف کرد و مقصر شناخته شد. مشخص شد که مبلغی که باید از طرف بیمه شده (یعنی ما) پرداخت می شد (که به آن Excess گفته می شود) دو برابر معمول است! چرا؟ چون شرکت بیمه مورد نظر سالهای سپری شده از زمان دریافت گواهینامه را از زمان دریافت گواهینامه استرالیایی حساب می کرد، و نه از زمان دریافت اولین گواهینامه (که در ایران گرفته شده بود).

نتیجه: از دید شرکت بیمه مقصر راننده بی تجربه محسوب می شد و مبلغ Excess دو برابر محاسبه گردید!

راه حل: سال بعد هنگام تمدید بیمه ماشین، Terms and Conditions و Product Disclosure Statement مربوط به بیمه های مختلف به دقت مطالعه شد بیمه دیگری انتخاب شد. اتفاقا تصادف دیگری صورت گرفت، اما این بار همه چیز مطابق میل بیمه گر (یعنی ما!) پیش رفت.

دو – یکی از دوستان قرارداد 24 ماهه سرویس موبایل امضا کرد. چند ماه متوالی قبض موبایل طبق انتظار مبلغ حدود 70 دلار ماهانه صادر می شد تا اینکه در یکی از ماه ها مبلغ قبض 500 دلار بود! چرا؟ چون مصرف داده (Data) در آن ماه از میزان تعیین شده ماهانه (که 500 مگابایت بود) عدول کرده و شرکت تامین کننده سرویس بابت هر مگابایت اضافه مبلغ هنگفتی شارژ کرده بود.

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

راه حل: ، Terms and Conditions و Product Disclosure Statement هنگام خرید محصول یا خدمت به دقت مطالعه گردد!

سه – پس از اتمام قرارداد اجاره خانه و هنگام تحویل، بنگاه معاملات ملکی که خانه از ایشان اجاره شده بود طی نامه ای به اطلاع رساند که خانه در شرایط اولیه نبوده و بسیاری از جزئیات نیاز به تعمیر / تعویض / شسته شدن دارد.

واقعیت: در بدبینانه ترین حالت، خانه مزبور به شکل اولیه تحویل داده شد (اگر نگویم بهتر و تمیزتر از روز اول بود!)

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

نتیجه: متحمل شدن هزینه تعمیر مواردی که از ابتدا نیاز به تعمیر داشته + 2 روز سابیدن برخی از نقاط خانه نظیر کرکره ها و در و دیوار که از روز اول هم تمیزتر بود!

راه حل: مطالعه شرایط، حقوق و وظایف پیش از امضای قرارداد.

اطمینان دارم که دوستان با موارد مشابه بسیاری برخورد کرده یا شنیده اند.

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

مطلبی می خواندم در مورد لهجه نوشته Anthea Fraser Gupta از دانشگاه لیدز انگلستان. خلاصه مطلب در زیر آمده است و لینک مطلب در ادامه آن.

لهجه چیست؟

• لهجه نحوه ادای یک زبان است و در نتیجه غیر ممکن است کسی لهجه نداشته باشد.
• برخی افراد تصور می کنند لهجه ندارند یا شخص دیگری لهجه غلیظی دارد. اما از نظر زبانشناسان هر دوی این افراد دارای لهجه هستند.
• برخی از لهجه ها به عنوان "لهجه مرجع" شناخته شده اند. به عنوان مثال 'General American'  یا 'RP' در زبان انگلیسی. اما این لهجه های مرجع لزوما دارای ریشه زبانشناسی یا زیبایی شناختی نبوده و در اثر بسیاری از عوامل نظیر رسانه ها (شبکه های خبری، فیلم، رادیو...) شکل گرفته اند.
• لهجه افراد بخشی از هویت آنهاست. افراد برای اثبات تعلق به یک گروه اجتماعی لهجه آن گروه را جذب و به کار می برند.
• هنگام شنیدن هر لهجه ای حس منحصر به فردی به شنونده منتقل می شود که با توجه به پیشینه آن شنونده این حس متفاوت است. به عنوان مثال برای یک فرد متولد انگلستان لهجه منطقه خاصی از این کشور به عنوان لهجه زیبا یا متعلق به کلاس بالای اجتماع شناخته شده و لهجه دیگری بر عکس. اما این حس به شخص متولد آمریکا منتقل نمی شود هر چند هر دو انگلیسی زبان هستند.

آیا می توانم لهجه خود را تغییر دهم؟

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

چگونه لهجه خود را تغییر دهم؟

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

لینک مطلب:
http://linguistlist.org/ask-ling/accent.cfm#standard
 

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

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

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

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

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

هنگام تولید یک سرویس، موارد زیر با توجه به کاربرد این سرویس مورد توجه قرار می گیرد:

- نوع خدمتی که که سرویس ارایه می دهد (Type of Logic)

- میزان قابلیت استفاده مجدد از آن سرویس (Reusability)

- سرویس در چه حوزه و دامنه ای (Domain) از سازمان دسته بندی می شود

با توجه به موارد بیان شده، سرویس ها را می توان به سه دسته زیر تقسیم بندی کرد:

- Entity Services

- Task Services

- Utility Services

در نتیجه این دسته بندی، لایه های زیر ایجاد می گردد:

Entity Services:

در هر سازمان با توجه به حوزه خدمات و نوع تجارت آن، موجودیتهای مختلفی وجود دارند. به عنوان مثال، تقریبا در همه سازمانهای موجودیت "پرسنل" (Employee) وجود دارد. سرویس هایی که بر اساس موجودیتهای (Entities) مورد نیاز سازمان ایجاد می شوند در دسته بندی Entity Services قرار می گیرند. این دسته از سرویس ها دارای قابلیت استفاده مجدد (Reusability) بالایی هستند چرا که وابسته به یک وظیفه (Task) یا پروسه خاص سازمانی نبوده و مستفل از عملیات سازمانی با حیات خود ادامه می دهند.

Task Services:

سرویسی که عملکرد آن به طور مستفیم با کار یا وظیفه ای (Task) در سازمان مرتبط باشد در این دسته بندی قرار می گیرد. مثلا سرویس "تولید گزارشات مالی" در این دسته بندی قرار می گیرد. با توجه به ماهیت این نوع از سرویس ها، قابلیت استفاده مجدد این سرویس ها کم است.

Utility Services:

سرویس های دسته بندی شده در دو مورد بالا همگی وابسته به موجودیت یا وظیفه ای خاص مرتبط با سازمان مورد نظر هستند. در مواردی لازم است که سرویسهای ایجاد شوند که وابستگی مستقیم به امور سازمانی یا تجارت خاصی ندارند. این گونه سرویس ها سرویس هایی هستند که قابلیت استفاده مجدد بالایی داشته و در بسیاری از کاربردها مورد استفاده قرار می گیرند. سرویس "ثبت وقایع" (Log) کاندید خوبی برای این دسته بندی است.

جدول زیر خلاصه ای از این دسته بندی را نمایش می دهد:

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

دسته بندی سرویس ها در شرکت کالایاب

پس از تحلیل نیازمندیهای شرکت و برگزاری چندین جلسه با حضور معمار سازمانی (Enterprise Architect)، معمار راه حلها (Solutions Architect)، معمار اطلاعات سازمانی (Information Architect) و همچنین چند نماینده از بخش های مختلف سازمان (Subject Matter Experts)، تصمیم گیری شد که لایه های زیر برای دسته بندی سرویس ها در شرکت کالایاب مورد استفاده قرار گیرد:

- Task Service Layer

- Entity Service Layer

- Utility Service Layer

- External Partners Service Layer

دسته بندی چهارم (External Partners Service Layer) به این منظور پیشنهاد شده است که شرکت کالایاب از بسیاری از خدمات دهندگان خارج از سازمان برای پیشبرد اهداف سازمانی خود استفاده خواهد کرد. به عنوان مثال، هنگامی که درخواست مشتری برای استعلام قیمت در مورد نوع خاصی شکلات به شرکت می رسد، شرکت باید از تامین کنندگان شکلات استعلام قیمت کرده و پایین ترین قیمت را به مشتری پیشنهاد دهد (برای اطلاعات بیشتر در مورد شرکت تخیلی کالایاب به اینجا مراجعه کنید).

به این منظور، شرکت کالایاب برای اتصال به Web Service های تامین کنندگان، سرویسی خاص طراحی و اجرا خواهد کرد که وظیفه آن صدا زدن (Service Call-out) سرویس های خارجی است. هرچند می توان این سرویس را در دسته بندی Task Services قرار داد، تیم تصمیم گیرنده برای شفافیت بیشتر و جداسازی بهتر لایه ها از نظر کاربرد، تصمیم بر ایجاد لایه چهارم External Partners Service Layer گرفت.

جدول زیر نمونه ای از دسته بندی ها و سرویس های موجود در هر دسته بندی را در شرکت کالایاب نمایش می دهد:

Service Layer	Service Name	Service Description
Task Service Layer	ManageOrder	This service handles orders from the point it is made by customer, up to the point the order is fulfilled.
	GenerateFiscalReport	Responsible to generate financial reports
	...	...
Entity Service Layer	Supplier	External Supplier
	Employee	Company’s internal employee
	Product	A particular product (e.g. X Chocolate, Y Flower, etc.)
	Order	An order made by a customer
	Customer	A customer making an order
	...	...
Utility Service Layer	Exception Handling	Service handling exceptions
	Logging	Service responsible for logging different activities
	Notification	Responsible for notifying users (e.g. when an order cannot be fulfilled successfully, a notification email is sent to sales team to manually handle the situation
	...	...
External Partners Service Layer	GetQuote	Send quote request to external suppliers and get the result
	SendShipmentRequest	Send shipment request to successful supplier to send the product to the customer
	...	...

<بخش قبل   بخش بعد>

برای اطلاعات بیشتر به اینجا مراجعه کنید.

Facebook gave a MySQL Tech Talk where they talked about many things MySQL, but one of the more subtle and interesting points was their focus on controlling the variance of request response times and not just worrying about maximizing queries per second.

But first the scalability. Facebook's OLTP performance numbers were as usual, quite dramatic:

- Query response times: 4ms reads, 5ms writes.

- Rows read per second: 450M peak

- Network bytes per second: 38GB peak

- Queries per second: 13M peak

- Rows changed per second: 3.5M peak

- InnoDB disk ops per second: 5.2M peak

Some thoughts on creating quality, not quantity:

بلكه مرگ ملتي است كه گدايي را قناعت؛

بي عرضگي را صبر

و با تبسمي بر لب اين حماقت را حكمت خداوند مي نامد.

گاندي