2009/05/27

‫‫DatePicker استاندارد دات نت برای تقویم ایرانی

DatePicker یک بار دیگر بعد از آن که خودمان نتوانستیم یکی دیگر از نیازهای کامپیوتری‌مان را برطرف کنیم، مایکروسافت به یاریمان آمد و این بار قرار است DatePicker و Calendar مخصوص ما ایرانی‌های زبر و زرنگ(!) را به صورت استاندارد و بدون باگ برایمان بسازد. من در اینجا شنیده‌ام که این امکان در دات نت ۴٫۰ اضافه خواهد شد. واقعا دست مایکروسافت و بقیه توسعه دهندگان دنیا درد نکند که بعد از آن همه تنبلی و تفرقه در ایجاد یک کدپیج استاندارد و واحد (ایران سیستم، سایه و پانیذ را به یاد می‌آورید؟) برایمان کدپیج یک دست درست کرد. دستش درد نکند که برایمان کلاس PersianCalendar درست کرد و حالا هم می‌خواهد در بازار قمر در عقرب DatePickerهای وطنی برایمان یک نسخه محلی شده از DatePicker بسازد. تازه آن هم بدون هیچ چشم داشتی حتی در حد ۱ سنت! ای کاش مجانا یک سری نرم افزار مالی-اداری مخصوص قوانین اداری ایران هم درست می‌کردند تا رسما در این آشفته بازار را ببندیم!




2009/05/24

OTRS config files and SysConfig

All OTRS configurations are saved in 3 config files named "config.pm", "ZZZAuto.pm" and "ZZZAAuto.pm". OTRS in order to retrieve any specific configuration entry, searches these files in a special order. If a specific entry is found in a config file, other config files are not searched. By this, "config.pm" has higher priority than "ZZZAuto.pm" and "ZZZAuto.pm" itself has a higher priority than "ZZZAAuto.pm". I dub "ZZZAuto.pm" tiny config file and dub "ZZZAAuto.pm" the main config file afterward.
It's possible to change all entries of main config file via SysConfig through UI. Consider that there are some special config entries that does not exists in main config file. One example is database connection string. Such settings can not be edited by SysConfig. Main config never changes but tiny config file is changed everytime you change an entry via SysConfig.
If you're going to change an entry that currently resides in "config.pm", the only way is changing "config.pm" directly even that entry contains in either main or tiny config files. In the other hand, SysConfig saves your changes in tiny config file but it does not take effect because a same entry exists in "config.pm".
Using SysConfig you can download all OTRS configurations except those that are not present in main config file (like database connection string). This config file indeed is our lovely tiny config file that it is downloaded for users. You can change this downloaded file, add or edit your desired entries and then upload them back to OTRS again. By uploading a new configuration file, this new uploaded file is replaced with OTRS tiny config file.




‫نحوه خطایابی عملیات ارسال/دریافت ایمیل

debug یکی از مشکلاتی که همیشه در آزمایش و راهبری پروتکل ECE به وجود می‌آید مشکلات مربوط به ارسال/دریافت ایمیل است. متاسفانه امکانات اولیه کلاس‌ها و کامپوننت‌های این کار اطلاعات چندان کاملی از خطای رخ داده به دست نمی‌دهند و گاها به یک خطای timed out بسنده می‌کنند. به عنوان مثال به خطای زیر که حاصل اجرای عملیات ارسال ایمیل با کلاس SmtpClient است توجه فرمایید:

(SendingMailException): The operation has timed out.,
(SmtpException): The operation has timed out.,

در این جور مواقع می‌توانید کلیه فعالیت‌های System.Net را زیر نظر بگیرید، شاید که مشکل ارسال/دریافت ایمیل را پیدا کردید. دقت کنید که با انجام این کار هر فعالیتی که بر روی TCP/IP انجام گیرد log شده و حجم فایل log در یک چشم به هم زدن به چندین مگابایت خواهد رسید. علاوه بر این پیدا کردن اطلاعات مورد نظر در این حجم زیاد اطلاعات کار چندان ساده‌ای نیست. در ادامه بخشی از این اطلاعات به عنوان نمونه آمده است:

System.Net.Sockets Verbose: 0 : [2616] Socket#23006966::Send()
System.Net.Sockets Verbose: 0 : [2680] Socket#23006966::Dispose()
System.Net.Sockets Error: 0 : [2616] Exception in the Socket#23006966::Send - A blocking operation was interrupted by a call to WSACancelBlockingCall
System.Net.Sockets Verbose: 0 : [2616] Exiting Socket#23006966::Send()     -> 0#0
System.Net Error: 0 : [2616] Exception in the SmtpClient#49662634::Send - Unable to write data to the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall.

حال برای فعال کردن «خطایابی» در برنامه خودتان کافی است کد زیر را به web.config یا app.config خود اضافه کنید. این کد در بالاترین سطح و درست زیر <configuration> اضافه می‌شود. همان جایی که <appSettings> و <system.web> قرار دارند:

<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net" >
<listeners>
<add name="MyTraceFile"/>
</listeners>
</source>
<source name="System.Net.Sockets">
<listeners>
<add name="MyTraceFile"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add
name="MyTraceFile"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="d:\users\System.Net.trace.log"/>
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
<add name="System.Net.Sockets" value="Verbose" />
</switches>
</system.diagnostics>




2009/05/19

‫وضعیت Xml Namespace در پروتکل ECE

xml-ns بالاخره بعد از مدت‌ها تکلیفمان با namespace استفاده شده در تگ Letter ایکس‌ام‌ال‌های «ارسال» و «رسید» در پروتکل ECE معلوم شد، البته تقریباً. این namespace که برای «ارسال» برابر است با "http://www.irica.com/ECE/1383-12/SendSchema" و برای «رسید» برابر است با "http://www.irica.com/ECE/1383-12/ReceiptSchema" برای ما و خیلی از پیاده‌سازان دیگر ابهام داشت. به حدی که بعضی‌ها مثل ما مجبور شدند با چند تا از همکارانشان در دیگر شرکت‌ها بر سر بود و نبود این namespaceها به طور داخلی به توافق برسند.

برای حل این مشکل حدود یک ماه پیش با چند نفر از طراحان اصلی پروتکل ECE تماس گرفتم و فهمیدم که قرار است نسخه بعدی پروتکل این ابهام را از بین ببرد. علاوه بر این معلوم شد که بیشتر شرکت‌ها فرض را به اجباری بودن وجود این دو namespace قرار داده‌اند. خود بنده هم پس از دیدن خط targetNamespace="http://www.irica.com/ECE/1383-12/SendSchema" در فایل ‪1.xsd‬‎ که از سایت رسمی پروتکل ECE قابل دریافت است و مطالعه‌ای که روی موضوع namespaceها در Xml داشتم دریافتم که وجود دو namespace فوق الذکر در ایکس‌ام‌ال‌های «ارسال» و «رسید» اجباری هستند. ضمنا هر نوع namespace دیگری که در ایکس‌ام‌ال‌های پروتکل قرار گیرند بی‌تاثیر و غیر ضروری بوده و بهتر است برای خوانایی بیشتر Xmlها حذف شوند.




2009/05/16

‫خلاصه‌ای از مفاهیم Xml و Xml Namespace با نگاهی به پروتکل ECE

xml مدت‌ها بود که به دنبال فرصت مناسبی برای یادگیری بعضی اصطلاحات Xml و معنی آنها می‌گشتم. از آنجا که اصطلاحات به کار رفته در Xml تنوع خیلی زیاد و معانی شبیه به هم دارند، روال یادگیری نسبتاً سختی هم دارند. طی مدت اخیر برای این که پروتکل ECE را بیشتر بفهمم و بعضی مسائل آن مثل اجباری یا اختیاری بودن xmlns و یا بحث validation را بهتر بفهمم مجبور شدم این فرصت مطالعاتی را اجباراً برای خودم مهیا کنم! با این که نتیجه این مطالعه تقریبا شبیه بیشتر Glossaryهای رایج مثل این است ولی من سعی کرده‌ام آنهایی را که فعلا بیشتر نیاز دارم یا برایم مبهم‌تر هستند و خصوصا آنهایی که در بحث پروتکل ECE کاربرد بیشتری دارند را در اینجا بیاورم. مثال‌ها هم به دلیل اهمیت پروتکل ECE بر اساس نمونه Xml زیر که خود یک نامه بر اساس پروتکل ECE است، آورده شده‌اند:

<?xml version="1.0" encoding="utf-8"?>
<Letter 
xmlns="http://www.irica.com/ECE/1383-12/SendSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Protocol Name="ECE" Version="1.01" />
<Software 
SoftwareDeveloper="http://afsharm.blogspot.com/" 
Version="1.0.0.0" 
GUID="A9032C8A-B4E9-4c06-8CA2-04D440547FAF" />
<Sender Organization="متروی تهران" 
Department="نیروی انسانی" 
Position="جانشین" 
Name="حسین فرمند" 
Code="765" />
<Receiver Organization="شهرداری اصفهان" 
Department="طرح و توسعه" 
Position="معاون" 
Name="فرخ پاینده" 
Code="174" 
ReceiverType="Origin" />
<OtherReceivers />
<LetterNo>649</LetterNo>
<LetterDateTime 
ShowAs="gregorian">
2008-01-15T14:43:46
</LetterDateTime>
<RelatedLetters />
<Subject>عید نوروز باستانی</Subject>
<Priority Code="0" Name="Normal" />
<Classification Code="0" Name="Normal" />
<Keywords>
<Keyword>تبریک</Keyword>
<Keyword>جدید</Keyword>
<Keyword>کارمند</Keyword>
</Keywords>
<Origins />
<Attachments />
</Letter>



 



در ادامه هر یک از مفاهیمی که برایم مهم بوده در حد امکان توضیح داده شده است. دو مفهوم namespace و XPath به دلیل اهمیت خیلی زیادی که برای خودم و پروتکل ECE داشت به طور کامل توضیح داده شده‌اند:



  • Markup: راهی برای معرفی شکل و شمایل یک متن. مثلا HTML یک Markup است که روش نمایش متون را در مرورگرها نمایش می‌دهد. برخلاف تصور عموم، Xml یک نوع Markup نیست بلکه ابزاری برای تعریف Markup است. Markupهایی مثل MathML یا همین پروتکل ECE خودمان. گاها به Markup، زبان یا language هم گفته می‌شود، مثلا به HTML، زبان HTML هم گفته می‌شود.
  • XML: مجموعه‌ای از قوانین و مقررات است که با استفاده از آن یک Markup یا زبان جدید تشریح می‌شود. یک فایل Xml متشکل است از مجموعه‌ای از elementها، tagها، nodeها و… Xml یک نسخه ساده شده‌ی SGML و خود SGML یک ساختار قدیمی و خیلی پیچیده برای انتقال اطلاعات است. بسیاری از فایل‌های امروزی ساختار Xml دارند. Xml خیلی از ساختارهای قدیمی از جمله CSV را از میدان رقابت به در کرده است.
  • Tag: به متنی که بین دو علامت کوچکتر و بزرگتر قرار دارد به علاوه خود علامت‌ها گفته می‌شود. مثل <Sender> و </Keywords>. معنی tag خیلی کوچک‌تر و ساده‌تر از element است.
  • Content: به هر گونه متنی که بین دو tag قرار دارد گفته می‌شود. مثل عبارت «عید نوروز باستانی» که در داخل تگ Subject قرار دارد.
  • Element: مجموعه کامل tag و content آن را element می‌گویند. مثل <LetterNo>649</LetterNo> و <Origins />. هر element می‌تواند شامل elementهای دیگری باشد. این تو در تو بودن elementها می‌تواند تا هر اندازه‌ای که لازم باشد تکرار شود. elementها نمی‌توانند هم‌پوشانی داشته باشند. یعنی تگ آغاز و پایان هر element باید به طور کامل بین تگ آغاز و پایان element والد خود باشد. به طور مثال تکه Xml زیر اشتباه می‌باشد:



<a>here<b>there</a>bye</b>



  • Attribute: یعنی اطلاعاتی که به صورت جفت‌های مقدار/داده در داخل tag به منظور توضیح رفتار آن element قرار می‌گیرد. مثل Code و Name در عنصر <Priority>.
  • Node: به هر کدام از مفاهیم tag، element و attribute یک Node گفته می‌شود.
  • Root Element: به elementی که دربرگیرنده همه elementهای یک سند xml است گفته می‌شود. هر سند xml فقط و فقط یک root element دارد نه کمتر نه بیشتر.
  • CDATA: راهی است برای وارد کردن Contentهای طولانی که شامل کاراکترهای خاصی هستند.مثلا شما هیچ وقت نمی‌توانید در content یک element علامت «کوچکتر از» یعنی "<" را وارد کنید بلکه به جای آن باید از ‪&lt;‬ استفاده شود. در بعضی حالات خاص اگر قرار باشد متنی که پر از علامت‌ها و کاراکترهای خاص هستند وارد شود دردسر زیادی به وجود خواهد آمد. ضمن آن که خوانایی متن هم کاهش می‌یابد. به عنوان نمونه به مثال زیر دقت کنید:



<Subject>
<![CDATA[if (a>b && c<d) e++;]]>
</Subject>



 



  • White Space: به مجموعه کاراکترهای فاصله (0x20)، Tab(0x09)، LF (0x0A) و CR(0x0D) گفته می‌شود. از ۲ تای آخر در سیستم عامل‌های مختلف به عنوان جدا کننده خطوط در سیستم فایل استفاده می‌شود. Xml Processorهای مختلف در شرایط مختلف، برخوردهای متفاوتی با white spaceها دارند. مثلا بین هر دو attribute هر تعداد هم white space وجود داشته باشد مشکلی در ساختار xml به وجود نمی‌آید. این یعنی هر attribute را می‌توان در یک خط جداگانه تعریف کرد. در نقطه مقابل، white spaceهای موجود در content یک element حفظ شده و در نظر گرفته می‌شوند. این یعنی اگر content یک element از چندین خط نوشته تشکیل شده بود در content مربوطه کلیه کاراکترهای CR/LF هم ذخیره شده و در نمایش‌های بعدی (مثلا درج اطلاعات xml در یک دیتابیس) هم نمایش داده خواهند شد.
  • DTD: راهی است برای کشف این نکته که آیا یک سند xml خاص مطابق با یک زبان یا markup خاص هست یا نه. این اعتبار سنجی از منظر واژگان (Vocabulary) و ساختار (Grammar) بررسی می‌شود. DTD رقیبی به نام Xml Schema دارد. DTD از Schema خیلی قدیمی‌تر و تقریبا همانی است که برای اعتبار سنجی اسناد SGML استفاده می‌شده در حالی که Xml Schema جدیدتر، راحت‌تر و رایج‌تر است.
  • Xml Schema: راهی است برای اعتبار سنجی یک سند Xml. این اعتبار سنجی از دو دیدگاه واژگان (Vocabulary) و ساختار (Grammar) انجام می‌شود. Xml Schema رقیبی جدی و در خیلی از موارد جایگزینی برای DTD محسوب می‌شود.
  • Namespace: هر سند xml شامل یک سری tag و attribute است به علاوه یک ساختار کلی که نشان می‌دهد اجزای آن چطوری با هم ارتباط دارند. این اجزا را Vocabulary و ساختار آنها را Grammar می‌نامند. به مجموعه‌ای از vocabularyهای مرتبط با هم که یک زبان یا markup مشخص را تعریف می‌کنند namespace گفته می‌شود. مثلا کلمات نامه، ساختار، نمایش، نوشته، استفاده، رفتار و… بخشی از vocabulary زبان فارسی و در نتیجه عضو namespace زبان فارسی هستند. Namespaceها فقط vocabulary یک زبان را مشخص می‌کنند و کاری به grammar آن ندارند. به عنوان مثال تمکیلی به مجموعه Letter، Software، Version، Organization، Code و OtherReceivers هم به عنوان بخشی از vocabulary پروتکل ECE دقت فرمایید. این مجموعه متعلق به namespace پروتکل ECE هستند.


namespaceها به صورت یک attribute تعریف می‌شوند. ns (مختصر شده namespace) را هم می‌توان با نام و هم بدون نام تعریف کرد. مثال:




<Letter 
xmlns="http://www.irica.com/ECE/1383-12/SendSchema">



 



در مثال بالا تگ Letter به عنوان عضوی از ns مربوطه تعریف شده و کلیه elementهای زیرمجموعه آن و attributeها و تگ‌ها آنها هم در صورتی که صراحتا عضو ns دیگری اعلام نشده باشند، عضوی از این ns خواهند بود. در روش بی‌نام نیازی به استفاده از prefix در ابتدای نام tagها یا attributeها نیست. در هر تگ فقط یک ns بی‌نام را می‌توان تعریف نمود.



در تعریف ns با نام باید از ساختار زیر تبعیت کرد:




<Letter
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">





 



یعنی اول عبارت xmlns:‎ آمده و سپس یک prefix برای ns مورد نظر تعریف می‌شود مثل xsi یا xsd. بعد از آن هم یک علامت مساوی و سپس رشته معرفی کننده ns در داخل دابل کوتیشن می‌آید. رشته معرفی کننده چه در حالت بی‌نام و چه در حالت با نام هیچ معنی خاصی نداشته و می‌تواند هر چیزی باشد مثل نام یک شهر، شماره ملی یک شخص و یا یک عدد ۴ رقمی. تنها قاعده‌ای که باید رعایت شود این است که این رشته باید در محدوده nsهای استفاده شده در یک xml منحصر به فرد باشد. طراحان یک Xml معمولا یک آدرس اینترنتی (URL) را برای این رشته استفاده می‌کنند. بیشتر وقت‌ها چنین آدرسی اصلا وجود ندارد و صرفا نمایانگر نام شرکت یا موسسه، تاریخ و نسخه ns مورد نظر است. ولی بهتر است برای مطالعه احتمالی افراد در همان آدرس مشخصات و تعاریف ساختار xml مورد نظر قرار داده شود.



در صورتی که مثل مورد زیر یک تگ با ns بدون اسم تعریف شود، تمام elementهای زیرمجموعه آن هم خود به خود عضو ns آن می‌شوند مگر آنکه صراحتا خلاف آن خواسته شده باشد. در این روش نیازی به استفاده از prefix نیست.




<Letter
xmlns="http://www.irica.com/ECE/1383-12/SendSchema">
<Protocol Name="ECE" Version="1.01" />
</Letter>



 



در صورتی که از ns با اسم استفاده شود باید قبل از attributeها و تگ‌ها، prefix مربوطه اضافه شوند. مثل:




<?xml version="1.0" encoding="utf-8"?>
<Letter
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsi:a1/>
<xsd:a2 xsd:t1="somtehing"/>
<a3></a3>
</Letter>



 



در این مثال elementهای <Letter> و <a3> عضو هیچ nsی نیستند در حالی که a1 عضو xsi و a2 و t1 هم عضو xsd هستند.



  • XPath: یک زبان برای استخراج اطلاعات از یک ساختار Xml است. رابطه XPath با Xml مثل رابطه SQL با دیتابیس است. به عنوان مثالی از XPath، برای استخراج موضوع (Subject) نامه از یک Xml پروتکل ECE در صورتی که از هیچ ns استفاده نشده باشد از XPath زیر استفاده می‌شود:



//Letter/Subject



 



و این XPath اگر از ns مربوط به پروتکل ECE (Send) یعنی "http://www.irica.com/ECE/1383-12/SendSchema" استفاده شود به شکل زیر در می‌آید:




//ltr:Letter/ltr:Subject



 



در مثال دوم فرض شده است که ns مربوطه بدون نام تعریف شده و ضمنا پیشوند ltr پیشوندی است که در داخل کد برنامه به آن اختصاص داده شده نه در تعریف ns یعنی:




<?xml version="1.0" encoding="utf-8"?>
<Letter
xmlns="http://www.irica.com/ECE/1383-12/SendSchema">
<Subject>دبیرخانه</Subject>
</Letter>



 



البته اگر xml به صورت زیر تعریف شده بود:




<?xml version="1.0" encoding="utf-8"?>
<Letter
xmlns:ltr="http://www.irica.com/ECE/1383-12/SendSchema">
<Subject>دبیرخانه</Subject>
</Letter>





 



آنگاه Xpath دوم بدون خروجی خواهد شد. چون در این حالت ns مربوطه همراه با پیشوند ltr تعریف شده بود در حالی که نه تگ Letter و نه تگ Subject هیچ کدام از این پیشوند استفاده نکرده‌اند. اگر قرار باشد از XPath دوم استفاده شده و خروجی دریافت گردد باید Xml فوق را به شکل زیر عوض کرد:




<?xml version="1.0" encoding="utf-8"?>
<ltr:Letter
xmlns:ltr="http://www.irica.com/ECE/1383-12/SendSchema">
<ltr:Subject>دبیرخانه</ltr:Subject>
</ltr:Letter>





 



ذکر این نکته خیلی خیلی ضروری است که اگر در یک xml یک سری ns با نام (یعنی دارای پیشوند) تعریف شده ولی هیچ کدام از تگ‌ها یا attributeها از استفاده نکرده باشند، می‌توان آن nsها را پاک کرد بدون آن که هیچ اختلالی در عملکرد xml مربوطه به وجود بیاید. مثلا در نمونه پروتکل ECE که در ابتدای متن آمده است، namespaceهای xsi و xsd کاملا روی اجزای xml داده شده بی‌تاثیر هستند و می‌توان آنها را محض خوانایی بیشتر از xml حذف کرد.



----------------------------



 



نکته تکمیلی ۱: هر آنچه که در Xml موجود است از جمله تگ‌ها و attributeها، به کوچکی و بزرگی حروف حساس (Case Sensitive) هستند.



نکته تکمیلی ۲: اگر encoding خط اول هر xml برابر utf-8 تعریف شده باشد (که در بیشتر مواقع همین طور است)، آنگاه استفاده از هر نوع کاراکتر فارسی و غیر فارسی در Contentها و مقادیر داخل دابل کوتیشن attributeها مجاز است.



نکته تکمیلی ۳: برای مطالعه تکمیلی به این مفاهیم توجه کنید: XSLT, XSD, Base64, URI, URL, URN, Well-formed Xml



نکته تکمیلی ۴: این نوشته بر اساس کتاب Learning XML, Erik T. Ray نوشته شده است.



 



مراجع:






2009/05/14

‫FOSS چیست؟

FOSS مقدمه
FOSS یا Free/Open Source Software یعنی نرم افزارهای آزاد و نرم افزارهای کد باز. به عبارتی FOSS نمایانگر دو نوع نرم افزار می‌باشد یکی نرم افزارهای آزاد (Free) و دیگری نرم افزارهای کد باز (Open Source).

نرم افزارهای آزاد
در مقابل نرم افزارهای آزاد (Free)، نرم افزارهای Proprietary قرار دارند. نرم افزارهای Proprietary آن گونه که در ممالک متمدن رایج است بر اساس اجازه‌نامه‌های (License) خاصی منتشر می‌شوند که این اجازه‌نامه‌ها کاربر را از هر گونه تغییر در نرم افزار و یا استفاده از آن در مقاصدی به غیر از مقاصد تعریف شده در اجازه‌نامه آن منع کرده است. مثلا ویندوز ویستا یک نرم افزار Proprietary است. در نتیجه مطابق اجازه‌نامه ویندوز ویستا حق ندارید بعضی dllهای خاص آن را دستکاری کنید. علاوه بر این حق استفاده از ویندوز ویستا را مثلا در سرور شبکه‌ای با بیش از ۱۰ کاربر ندارید. از طرفی دیگر، نرم افزارهای آزاد را هر طور که دلتان خواست می‌توانید دستکاری کرده و به هر منظوری که خواستید می‌توانید استفاده کنید. نرم افزارهای آزاد هم می‌توانند همچون نرم افزارهای Proprietary پولی باشند. در واقع تنها تفاوت نرم افزار آزاد و نرم افزار Proprietary در آزادی نحوه استفاده از آن است و الا هر دو می‌توانند پولی بوده و لزومی ندارد که هیچ کدام از این دو کد باز (Open Source) هم باشند. مثلا مایکروسافت می‌تواند MS Office را یک نرم افزار آزاد اعلام کرده ولی همچنان در قبال هر نسخه از آن همان پولی قبلی را دریافت کرده، کاربران را از توزیع مجدد آن منع و کد منبع (Source Code) آن را هم به هیچ کسی ندهد. معادل واژه آزاد در انگلیسی یعنی Free واژه‌ای با دو معنا است که یک معنی آن آزاد و آزادی و معنی دیگر آن رایگان است. که البته در اصطلاح Free Software از معنای اول آن یعنی آزادی استفاده شده است. خوشبختانه واژه آزادی در فارسی فقط یک معنی و آن هم معنی درست آن را می‌رساند.

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

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

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

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

 

منابع




2009/05/09

‫OTRS::ITSM و پشتیبانی آن از ITIL

«این نوشته تقریبا خلاصه‌ای از راهنمای OTRS::ITSM 1.2 – Basic است.»

مقدمه
ITIL مجموعه‌ای از راهنمایی‌ها، روش‌ها و تجارب مفید گروه OGC است که در اداره امور IT در ادارات، سازمان‌ها و مجموعه‌های بزرگ کاربرد فراوانی دارد. به عبارت دیگر اگر مدیران IT روش انجام کار و تقسیم‌بندی‌هایشان را بر اساس ITIL انجام دهند در راهبری زیر مجموعه تحت امرشان موفق‌تر خواهند بود. ITIL که استاندارد ISO 20000 هم بر اساس آن ابداع شده به بخش‌های مختلفی تقسیم می‌شود. IT Service Management یا همان ITSM یکی از همین بخش‌هاست که OTRS هم در حال حاضر قسمت‌هایی از آن را پیاده سازی کرده است. ITSM شامل ۱۱ زیر بخش مختلف است که این زیربخش‌ها در ۲ دسته کلی Service Support و Service Delivery قرار دارند. نرم‌افزار OTRS در حال حاضر (اردیبهشت ۱۳۸۸) پنج تا از این زیر بخش‌ها را پیاده‌سازی کرده است که عبارتند از: Service Desk Function، Incident Management، Problem Management، Configuration Management و Service Level Management.

‫بخش‌های مختلف Service Management در ITIL

 

معرفی زیربخش‌ها
Service Desk Function همان عملکرد کلی OTRS به عنوان یک سیستم مکانیزه واحد پشتیبانی است. Service Level Management از طریق اعمال «توافق سطح سرویس SLA» بر صف‌های داخلی OTRS محقق می‌شود. Incident & Problem Management هم مرتبط با مدیریت درخواست‌های (ticket) کاربران (مشتریان) سیستم است و در انتها Configuration Management نیز به معنی نگهداری و مدیریت اطلاعات CIها است. هر CI یا Configuration Item می‌تواند یک کامپیوتر، سخت افزار، نرم افزار، شبکه، محل قرارگیری یا… باشد. به عبارت دیگر CI هر چیزی در یک واحد IT است که نیاز به نگهداری و دانستن اطلاعاتی درباره آن هست. با مرتبط کردن درخواست‌ها (ticket) و سرویس‌ها با بانک اطلاعاتی CIها که به اختصار CMDB نامیده می‌شود می‌توان با استفاده از گزارشات سیستم، میزان مورد استفاده بودن یا خرابی هر یک از CIها را استخراج کرد. اگر جنبه  مالی سیستم‌های مدیریت اموال و دارایی معمول ادارات را در نظر نگیریم می‌توان CMDB در واحدهای IT را تا اندازه‌ای با سیستم مدیریت اموال و دارایی (Asset) در ادارات و سازمان‌ها شبیه به هم دانست. از آنجایی که خود OTRS به تنهایی از ITSM پشتیبانی نمی‌کند برای افزودن این امکانات به آن باید از ماژول‌های اضافه‌ای به نام OTRS::ITSM استفاده کرد. این مجموعه ماژول بخش‌های ذکر شده از مدیریت سرویس را به OTRS اضافه می‌کنند. در ادامه شرح مختصری از امکانات ITSM در OTRS که به واسطه این ماژول‌ها به آن افزوده می‌شود، می‌آید.

 

Incident and Problem Management
دم‌دست‌ترین امکان ITSM در OTRS همان Incident Management است. Incident را در فارسی می‌توان به «رخداد» ترجمه کرد. یک رخداد به خودی خود به معنی «مسئله» نیست بلکه یک جور اعلام وضعیت است. به وجود آمدن این وضعیت یا رخداد ممکن است به علت یک خرابی ساده یا پیچیده باشد و ممکن است هیچ خرابی در به وجود آمدن نقش نداشته باشد. مثلا وقتی که شما کولر اتاق‌تان را روشن می‌کنید ولی اتاق خنک نمی‌شود یک رخداد (Incident) به وجود می‌آید. تا زمانی که این رخداد بررسی نشود نمی‌توان آن را یک «مشکل» تلقی کرد. این رخداد ممکن است به علت بسته بودن دریچه کولر اتاق و در نتیجه خنک نشدن اتاق باشد (عدم وجود یک مشکل خاص)، ممکن است به علت پارگی کابل برق کولر باشد (خرابی ساده) یا ممکن است به علت سوختن موتور کولر باشد (خرابی پیچیده). در OTRS::ITSM برای اعلام یک Incident باید یک درخواست (ticket) از نوع Incident ثبت کرد.
Problem Management در OTRS::ITSM مشابه Incident Management است. با این تفاوت که Problem عمدتا توسط کارشناسان (agent) ثبت می‌شوند نه مشتری‌ها (Customer). Agentها که همان کارمندان بخش IT یک اداره هستند با ثبت شدن هر Incident آن را بررسی کرده و در صورتی که علت وقوع آن یک خرابی ساده یا پیچیده نباشد آن را برطرف می‌نمایند در غیر این صورت آن درخواست (ticket) را تبدیل به یک Problem کرده یا به ازای آن یک Problem جدید ثبت می‌کنند. معمولا Incidentها و Problemهای مختلف در صف‌های جداگانه‌ای ثبت شده و مسئولین پیگیری مختص به خود را دارند.

‫رابطه بین Incidetnt، Problem و دیگر بخش‌های Service Management

 

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

پشتیبانی چند سطحی

 

SLA
چه در مورد «Incident» و چه در مورد «Problem» از SLA برای تعیین زمان پاسخگویی به درخواست‌های موجود در یک صف استفاده می‌شود. با SLA چهار زمان «اولین پاسخگویی»، «زمان پاسخ تکمیلی»، «زمان تکمیل انجام درخواست» و «حداقل زمان بین دو درخواست» مشخص می‌شود. این ۴ زمان تکلیف کارشناسان (agent) و مشتری‌ها (agent) را با هم مشخص می‌کند و اگر به خوبی رعایت شود خیلی از دعواهای بین واحد کامپیوتر (کارشناسان) و کارمندان (مشتریان) را از بین می‌برد. SLAها را می‌توان بر اساس تقویم‌های مختلفی تعریف کرد. یعنی می‌شود ساعات کاری و روزهای تعطیل و غیر تعطیل را بر اساس یک تقویم از پیش تعریف شده معین نمود. برای آن که مدیریت مجموعه بتواند کنترل بیشتری روی انجام درخواست‌ها (چه Incident و چه Problem) داشته باشد راهی وجود دارد به نام «تصمیم گیری Decision». در این روش مدیر IT یا کارشناس مربوطه درخواست‌ها (ticket) را بررسی کرده و با ثبت یک یادداشت ویژه انجام آن را تایید یا ممنوع می‌کنند. به این مکانیزم Approval هم گفته می‌شود.

‫SLA و مفاهیم زمانی آن

 

CMDB
کار کردن با بانک اطلاعاتی CIها (CMDB) در OTRS خیلی راحت است. هر CI مثل یک کلاس یا آبجکت در دنیای برنامه‌نویسی است. یعنی هر CI از تعدادی property تشکیل می‌شود. هر property می‌تواند یک نوع داده ساده مثل integer یا string باشد یا این که می‌تواند یک نوع جدول مانند باشد. مثلا یک سرور می‌تواند ۱۰ عدد کارت شبکه و در نتیجه ۱۰ تا IP داشته باشد. یک property خود می‌تواند از نوع یک کلاس (CI) دیگر هم باشد. در OTRS::ITSM تعدادی کلاس از پیش تعریف شده وجود دارد که امکان ویرایش این کلاس‌های از پیش تعریف شده و همچنین تعریف کلاس‌های جدید در OTRS::ITSM وجود دارد. علاوه بر این امکانات می‌شود بین هر کدام از CIها با یکدیگر یا بین CIها و دیگر اقلام OTRS مثل درخواست‌ها (ticket) یا سرویس‌ها رابطه تعریف نمود. به این ترتیب می‌توان اطلاعات مفیدی مثل این که کدام CI بیشترین گزارش خرابی را به خود اختصاص داده یا کدام CI بیشترین استفاده را دارد را از سیستم استخراج کرد. یکی از اطلاعاتی که در مورد هر CI ثبت می‌شود «وضعیت عملیاتی» آن است. وضعیت عملیاتی هر CI طی مکانیزم خاصی روی دیگر CIها تاثیر می‌گذارد.