Payamvdn/NorthPersian_fa_wiki huggingface dataset:
تنها مردمی بودند که از آهن تلوریک استفاده کردند. در سال 1870، آدولف اریک نوردنسکیولد تخته سنگ های آهنی بزرگی را در نزدیکی منطقه خلیج دیسکو در گرینلند کشف کرد. نوردنسکیولد با علم به اینکه اینوئیت ها ابزارهایی را از شهاب سنگ کیپ یورک ساخته اند، عمدتاً به دلیل کشف سر جان راس مبنی بر استفاده بومیان گرینلند از چاقوهای آهنی، در خلیج فورچون در جزیره دیسکو فرود آمد تا به دنبال این ماده بگردد. اینوئیت ها به راس گفته بودند که آهن را از بلندی کوه، از محلی که دو تخته سنگ بزرگ در آن قرار داشتند، به دست آوردند. یکی بسیار سفت بود و نمی توان شکست، اما دیگری را به قطعات کوچک تری خرد می کردند که از آن گلوله های آهن بیرون می کشیدند و به صورت دیسک های مسطح برای چاقو می کوبیدند. نوردنسکیولد در جستجوی مکان ناموفق بود، تا اینکه توسط برخی از اینوئیت های محلی به مکانی به نام "Uivfaq" هدایت شد، جایی که توده های زیادی از آهن فلزی در اطراف آن پخش شده بود. او فرض کرد که این فلز منشأ شهاب سنگی دارد، زیرا هر دو حاوی مقادیر قابل توجهی نیکل هستند و هر دو دارای الگوهای Widmanstätten هستند. اکثر دانشمندان در آن زمان معتقد بودند که آهن "تلوریک
" اکسید نشده وجود ندارد و تعداد کمی از یافته های نوردنسکیولد را زیر سوال بردند. گوستاو ناوکوف در سال 1871 به گرینلند سفر کرد. اکسپدیشن او که به دینامیت و تجهیزات بالابر مسلح شده بود، سه نمونه بزرگ از آهن تلوریک را جمع آوری کرد، همچنین طبق بررسی نوردنسکیلد معتقد بود که آنها شهاب سنگ هستند، و آنها را برای مطالعه بیشتر به اروپا آورد. این نمونه ها در حال حاضر در سوئد, فنلاند و دانمارک یافت می شوند . یک بلوک 25 تنی اکنون در خارج از موزه Riksmuseum در استکهلم قرار دارد، یک 6.6 بلوک تن در خارج از موزه زمین شناسی در کپنهاگ، و یک بلوک 3 تنی را می توان در موزه تاریخ طبیعی در Kumpula، هلسینکی پیدا کرد. همراه Nauckhoff در سال 1871 KJV Steenstrup بود. با توجه به شرایطی مانند شکل تخته سنگ ها، که اغلب دارای گوشه های تیز یا لبه های دندانه دار بودند که مشخصه شهاب سنگ ها نیست (که به طور قابل توجهی در هنگام ورود به اتمسفر فرو می ریزد )، یا این واقعیت که بسیاری از آنها دارای مناطقی بودند که با سنگ بازالت پوشیده شده بودند، استین استراپ با نوردنسکیولد در مورد منشاء سنگ ها که توسط خودش ساخته شده بود، مخالفت کرد. در سال 1879، Steens
trup برای اولین بار این "نوع" را شناسایی کرد" 2 آهن" ، نشان می دهد که آن را نیز شامل سازه های Widmanstätten . استین استراپ بعداً آنچه را که پیدا کرد گزارش داد: در پاییز 1879، "من در رابطه با این موضوع کشف کردم، زیرا در یک قبر قدیمی در Ekaluit" ... "من 9" رو پیدا کردم" قطعات بازالت حاوی گلوله های گرد و قطعات نامنظم آهن فلزی." این قطعات با چاقوهای استخوانی، شبیه به آنهایی که راس به خانه آورده بود، و همچنین با ابزارهای سنگی معمولی کنار هم قرار داشتند. در حالی که 9 تکه های بازالت با توپ های آهنی ظاهراً مواد چاقوهای استخوانی بودند. این آهن نرم است و به خوبی در هوا نگهداری می شود، به همین دلیل برای استفاده به روشی که راس توضیح داده است مناسب است. سنگی که آهن در آن ظاهر می شود، نوعی فلسپار بازالت معمولی و دانه درشت است. این کشف اهمیت دوچندانی دارد، اولاً به این دلیل که اولین بار است که ما موادی را می بینیم که "اسکیموها از آن چاقوهای مصنوعی ساخته اند" و ثانیاً به این دلیل "که نشان می دهد برای این منظور از آهن تلوریک استفاده کرده اند" . پس از کشف در گور در Ekaluit ، Steenstrup بسیاری از رخنمون های بزرگ بازالت حاوی این
"نوع را" پیدا کرد." 2 آهن" . از آنجایی که "نوع 2" دانه در بازالت آتشفشانی جاسازی شده است که با سنگ بستر زیرین مطابقت دارد، Steenstrup توانست نشان دهد که آهن از منابع زمینی یا تلوریک است. استین استراپ در گزارش خود افزود: "این لایه خاص از بازالت از بالا به پایین با دانه های آهن در هر اندازه از کسری از میلی متر تا طول 18 پر شده است" . میلی متر با عرض 14 میلی متر، که بهترین چیزی است که من پیدا کردم. ... این اتو وقتی جلا داده می شود، چهره های زیبای Widmannstätten را نشان می دهد. ... "اکنون ثابت شده است که نیکل-آهن فلزی با شکل های Widmannstätten نیز یک کانی تلوریک است" و در نتیجه وجود نیکل همراه با ساختار بلوری مشخص برای دادن ویژگی شهاب سنگ ها به بلوک های آهنی کافی نیست. یافته های Steenstrup بعداً توسط متخصص شهاب سنگ J. Lawrence Smith در سال 1879 و سپس توسط Joh Lorenzen در سال 1882 تأیید شد. آهن تلوریک بسیار کمیاب که در غرب گرینلند یافت می شود از آن زمان تحت مطالعه بوده است. وقوع. علاوه بر ذخایر جزیره دیسکو، آهن بومی از خلیج فورچون، ملمفورد، آسوک و سایر نقاط در امتداد ساحل غربی گرینلند گزارش شده است. مکان های دیگر
عبارتند از: آلیاژهای نیکل-آهن بومی با Ni 3 Fe تا Ni 2 Fe به صورت رسوبات پلاسر حاصل از سنگ های اولترامافیک ایجاد می شوند. Awaruite در سال 1885 از نیوزلند توصیف شد. مراجع. 1-https://web.archive.org/web/20160303180205/http://www.handbookofmineralogy.com/pdfs/iron.pdf"Handbook of Mineralogy". Archived from the original (PDF) on 2016-03-03. Retrieved 2012-08-19. 2-https://www.mindat.org/loc-106121.html "MinDat". Keswick, VA: Hudson Institute of Mineralogy. Retrieved 2021-12-31. 3- http://www.webmineral.com/data/Iron.shtml."WebMineral". 4- https://books.google.com/books?id=c947L8YJerUC Buchwald, Vagn Fabritius (2005).Historisk-filosofiske Skrifter 29. Det Kongelige Danske Videnskabernes Selskab (The Royal Danish Academy of Sciences and Letters). pp. 35–37. 5-Buchwald, Vagn Fabritius; Mosdal, Gert (1985). https://books.google.com/books?id=6z8lVGAfBtsC
نیروگاه بادی سراب نام نیروگاهی در دست ساخت در نزدیکی شهر سراب در استان آذربایجان شرقی می باشد، که با توان تولید ۲۵ مگاوات با تبدیل انرژی جنبشی باد به الکتریکی، برق تولید خواهد کرد. شرح برنامه ساخت. این نیروگاه شامل ۱۰ توربین بادی ۲٫۵ مگاواتی خواهد بود که کار مطالعات بادسنجی از سال ۱۳۹۵ توسط شرکت گروه برق و انرژی صبا شروع شده است. همچنین قرارداد احداث این نیروگاه به ظرفیت ۲۵ مگاوات با مشارکت شرکت ABO Wind آلمان خواهد بود.
آزمون مرد یا پسر توسط دانشمند کامپیوتر دونالد کنوت به عنوان ابزاری برای ارزیابی پیاده سازی زبان برنامه نویسی ALGOL 60 پیشنهاد شد. هدف از این آزمون تشخیص کامپایلرهایی بود که به درستی «مرجع بازگشتی و غیر محلی » را از آنهایی که این کار را انجام نداده بودند، پیاده سازی کردند. تعداد زیادی مترجم ALGOL60 وجود دارند که برای مدیریت صحیح مراجع بازگشتی و غیر محلی طراحی شده اند، و من فکر کردم شاید یک برنامه آزمایشی کوچک ممکن است مفید باشد. از این رو من روال ساده زیر را نوشته ام که ممکن است کامپایلر مرد را از کامپایلر پسر جدا کند. - دونالد کنوت مثال کنوت. در ALGOL 60 : begin real procedure A(k, x1, x2, x3, x4, x5); value k; integer k; real x1, x2, x3, x4, x5; begin real procedure B; begin k := k - 1; B := A := A(k, B, x1, x2, x3, x4) end; if k ≤ 0 then A := x4 + x5 else B end; outreal(1, A(10, 1, -1, -1, 1, 0)) end این یک درخت از فریم های فراخوانی "B" ایجاد می کند که به یکدیگر و فریم های فراخوانی حاوی "A" اشاره می کنند، که هر کدام کپی مخصوص به "خود" را دارند که هر بار که "B" مرتبط فراخوانی می شود، تغییر می کند. تلاش برای
کار بر روی کاغذ احتمالا بی نتیجه است، اما برای "k" = 10، پاسخ صحیح -67 است، علیرغم این واقعیت که کنوت در مقاله اصلی آن را 121- حدس زده است. حتی ماشین های مدرن به سرعت فضای پشته ای برای مقادیر بزرگ تر "k" که در جدول زیر نشان داده شده اند تمام می شود ( ). توضیح. سه ویژگی Algol در این برنامه استفاده شده است که پیاده سازی صحیح آنها در یک کامپایلر دشوار است: با این حال، این چیزها چیزی نیست که آزمون در مورد آن است. آنها صرفاً پیش نیازهایی برای معنی دار بودن آزمون هستند. آنچه "در مورد" آزمون است این است که آیا ارجاعات مختلف به "B" به نمونه "صحیح" "B" می رسد - نمونه ای که به همان نمادهای محلی "A" دسترسی دارد که "B" که مرجع را ایجاد کرده است. به عنوان مثال، یک کامپایلر "پسر" ممکن است به جای آن برنامه را کامپایل کند تا "B" همیشه به بالاترین فریم تماس "A" دسترسی داشته باشد.
این مقاله در حال ترجمه از ویکی انگلیسی است لطفا حذف نشود. مدل سازی چندوجهی خاص دامنه یک پارادایم توسعه نرم افزار است که در آن هر دیدگاه به طور صریح به عنوان یک زبان خاص دامنه (DSL) جداگانه بیان می شود. توسعه موفق یک سیستم سازمانی مدرن نیازمند همگرایی چندین دیدگاه است. تحلیلگران کسب وکار، کارشناسان دامنه، طراحان تعامل، کارشناسان پایگاه داده، و توسعه دهندگانی با انواع تخصص های مختلف همگی در فرآیند ساخت چنین سیستمی مشارکت دارند. محصولات کاری مختلف آنها باید مدیریت، هماهنگ و یکپارچه شوند تا یک سیستم در حال اجرا تولید شود. هر مشارکت کننده در فرآیند توسعه یک زبان خاص برای حل مشکلات مربوط به دیدگاه خود در سیستم دارد. چالش در یکپارچه سازی این دیدگاه های مختلف و اجتناب از کافوفونی احتمالی زبان های مختلف، مشکل هماهنگی است. مدل سازی چندوجهی خاص دامنه زمانی امیدوارکننده است که با پارادایم های توسعه سنتی مانند برنامه نویسی با یک زبان واحد و مدل سازی چندمنظوره مقایسه شود. برای بهره برداری از مزایای این پارادایم جدید، باید مشکل هماهنگی را حل کرد. این مشکل همچنین به عنوان مشکل پراکندگی در زمینه مدیریت مدل های جهانی شناخته می
شود. یک پیشنهاد برای حل این مشکل، روش هماهنگی است. این یک روش سه مرحله ای است که برای غلبه بر موانع یکپارچه سازی دیدگاه های مختلف و هماهنگی زبان های مختلف ارائه شده است. این روش نحوه (1) شناسایی و (2) مشخص کردن ارجاعات میان مرزهای زبان ها، یعنی همپوشانی های بین زبان های مختلف را تجویز می کند. در نهایت، این روش پیشنهاد های مشخصی برای (3) اعمال این دانش در توسعه واقعی در قالب انطباق، ناوبری و راهنمایی ارائه می دهد. مثال تشویقی سیستم های سازمانی مبتنی بر زبان های خاص دامنه متعدد بسیار رایج هستند. زبان هایی که متامدل آن ها در زبان نشانه گذاری قابل گسترش (XML) تعریف شده است، به ویژه در حال گسترش هستند. برای نشان دادن توسعه با زبان های متعدد، از یک مطالعه موردی استفاده می کنیم: سیستم Apache Open For Business (OFBiz). به طور خلاصه، OFBiz یک سیستم برنامه ریزی منابع سازمانی است که شامل اجزای استاندارد مانند موجودی، حسابداری، تجارت الکترونیک و غیره است. این اجزا با ترکیبی از زبان های مبتنی بر XML و کدهای جاوا معمولی پیاده سازی شده اند. به عنوان یک مثال، ما بر روی بخش مدیریت محتوا تمرکز می کنیم، به ویژه یک مورد استفاده
که در آن کاربر مدیریتی یک نظرسنجی آنلاین ایجاد می کند، همانطور که در اسکرین شات زیر نشان داده شده است. این مثال را "مثال ایجاد نظرسنجی" می نامیم. شکل یک اسکرین شات از رابط کاربری مدیریتی برنامه مدیریت محتوا در یک نمونه OFBiz در حال اجرا را نشان می دهد. برای ایجاد یک نظرسنجی، کاربر فیلدهای فرم ورودی را پر کرده و دکمه به روزرسانی را فشار می دهد. این عمل یک نظرسنجی جدید ایجاد می کند که می توان آن را ویرایش کرده و در نهایت در وب سایت جلویی OFBiz منتشر کرد. در پشت صحنه، این مورد استفاده شامل چندین آثار نوشته شده در زبان های مختلف است. در این مثال، ما تنها به سه زبان از این زبان ها تمرکز می کنیم: زبان Entity، زبان Service و زبان Form. این سه زبان به طور تقریبی به ترتیب به مدل ساختاری، رفتار برنامه و نگرانی رابط کاربری در OFBiz اشاره دارند. زبان Entity برای توصیف مدل داده زیربنایی استفاده می شود و در نتیجه نحوه ذخیره سازی نظرسنجی ایجاد شده را تعیین می کند. زبان Service برای توصیف رابط سرویسی که وقتی کاربر دکمه به روزرسانی را فشار می دهد، فراخوانی می شود، استفاده می شود. در نهایت، زبان Form برای توصیف ظاهر بصری فرم
استفاده می شود. اگرچه این سه زبان برای چیزهای مختلف طراحی شده اند، اما نمی توان آن ها را به طور کامل از هم جدا کرد. رابط کاربری منطق خاصی از برنامه را فراخوانی می کند و این منطق برنامه داده های برنامه را دستکاری می کند. این مثال از نگرانی های غیر اورتوگونال است. زبان ها همپوشانی دارند زیرا نگرانی هایی که نمایندگی می کنند نمی توانند به طور کامل از هم جدا شوند. اکنون این سه زبان را به صورت پایین به بالا بررسی کرده و همپوشانی های آن ها را توضیح می دهیم. Entity DSL زبان Entity DSL ساختار داده ها را در OFBiz تعریف می کند. فهرست زیر تعریف موجودیت Survey را نشان می دهد که شیء تجاری است که نمایانگر مفهوم یک نظرسنجی است. کد در فهرست به وضوح قابل فهم است: موجودیتی به نام Survey با 10 فیلد تعریف شده است. هر فیلد یک نام و نوع دارد. فیلد surveyId به عنوان کلید اصلی استفاده می شود. این تعریف توسط یک مؤلفه مرکزی در OFBiz به نام entity engine بارگذاری می شود. entity engine یک شیء تجاری متناظر را نمونه سازی می کند. هدف entity engine مدیریت ویژگی های تراکنشی تمام اشیاء تجاری و تعامل با مکانیزم های مختلف پایداری مانند Java Data
base Connectivity، Enterprise JavaBeans یا حتی برخی از سیستم های قدیمی است. Service DSL زبان Service DSL رابط خدمات در OFBiz را مشخص می کند. هر سرویس بخشی از منطق برنامه سیستم را در بر می گیرد. هدف این زبان داشتن یک انتزاع یکنواخت از مکانیزم های مختلف پیاده سازی است. سرویس های فردی می توانند به زبان جاوا، یک زبان اسکریپتی یا با استفاده از یک موتور قواعد پیاده سازی شوند. فهرست زیر رابط سرویس createSurvey را نشان می دهد. علاوه بر نام، عنصر سرویس مکان و دستور فراخوانی پیاده سازی این سرویس را مشخص می کند. ویژگی default-entity-name مشخص می کند که این سرویس به موجودیت Survey اشاره دارد که در فهرست قبلی تعریف شده است. این یک همپوشانی بین دو زبان است، به ویژه آنچه به نام ارجاع نرم گفته می شود. یک مدل در Service DSL به یک مدل در Entity DSL اشاره دارد. این ارجاع در دو عنصر auto-attributes زیر استفاده می شود که ورودی و خروجی سرویس را به صورت ویژگی های تایپ شده مشخص می کنند. به عنوان ورودی، سرویس ویژگی هایی را می پذیرد که مربوط به تمام فیلدهای غیرکلید اصلی (nonpk) موجودیت Survey هستند و این ویژگی ها اختیاری هستند. به عنو
ان خروجی، سرویس ویژگی هایی را که مربوط به فیلدهای کلید اصلی (pk) موجودیت Survey هستند، یعنی در این مورد فیلد surveyId، باز می گرداند و این ویژگی ها اجباری هستند. هدف ارجاع میان زبان ها در اینجا کاهش تکرار است. ویژگی های سرویس createSurvey به فیلدهای موجودیت Survey مربوط می شوند و بنابراین تنها لازم است یک بار آن ها را مشخص کنیم. Form DSL زبان Form DSL برای توصیف چیدمان و ظاهر بصری فرم های ورودی در رابط کاربری استفاده می شود. این زبان از مفاهیم دامنه ای مانند Form و Field تشکیل شده است. فهرست زیر پیاده سازی فرم EditSurvey را نشان می دهد. این بار زبان Form DSL با زبان Service DSL همپوشانی دارد. ویژگی target فرم و عناصر alt-target مشخص می کنند که ورودی از ارسال این فرم باید به سرویس های updateSurvey یا createSurvey هدایت شود. عنصر auto-fields-service مشخص می کند که فرم باید شامل فیلدی باشد که به هر یک از ویژگی های سرویس updateSurvey (که مشابه ویژگی های سرویس createSurvey هستند) مربوط باشد. این اثر مشابهی از وارد کردن تعاریف از یک مدل دیگر را تولید می کند، همانطور که در مورد عناصر auto-attributes در فهرست قبلی ذک
ر شد. در پایین تر، می بینیم که می توان ظاهر این فیلدهای وارد شده مانند isAnonymous را سفارشی کرد. در نهایت، یک submitButton با عنوان محلی سازی شده اضافه می شود تا کاربر بتواند داده های خود را به سرویس ارجاع شده ارسال کند. مثال ایجاد نظرسنجی که در اینجا توصیف شده است با استفاده از مدل هایی در سه زبان مختلف پیاده سازی شده است. پیاده سازی کامل در واقع شامل زبان های بیشتری مانند Screen DSL برای مشخص کردن چیدمان صفحه ای است که فرم در آن قرار می گیرد و Minilang DSL که یک زبان دستکاری داده ها است که برای پیاده سازی سرویس استفاده می شود. با این حال، این سه زبان ایده اصلی ساختن هر نگرانی به صورت ملموس را نشان می دهند. این مثال همچنین یک روش ساده برای کاهش تکرار با اجازه دادن به همپوشانی جزئی زبان ها را نشان می دهد. Multi-level customization زبان های خاص دامنه ای مانند زبان های توصیف شده در بالا، بیان گری محدودی دارند. اغلب لازم است که قطعه کدهایی به زبان های عمومی مانند جاوا اضافه شوند تا عملکردهای خاصی که فراتر از دامنه زبان ها هستند پیاده سازی شوند. این روش را سفارشی سازی چندسطحی می نامند. از آنجا که این روش در تنظی
مات با زبان های متعدد به طور رایج استفاده می شود، آن را با ادامه مثال توضیح خواهیم داد. بیایید این مثال را "مثال ساخت PDF" بنامیم. فرض کنید می خواهیم یک فایل PDF برای هر پاسخ نظرسنجی به نظرسنجی های آنلاین که کاربران ایجاد می کنند بسازیم. ساخت فایل PDF خارج از دامنه زبان های ما است، بنابراین باید کد جاوا بنویسیم که بتواند یک کتابخانه PDF شخص ثالث را فراخوانی کند تا این عملکرد خاص را انجام دهد. دو اثر لازم است: اولاً، یک مدل سرویس اضافی که در زیر آمده است، در Service DSL که رابط سرویس خاص را تعریف می کند تا بتوان آن را در سطح مدل دسترسی کرد. مدل سرویس مکان پیاده سازی و ویژگی های ورودی و خروجی را توصیف می کند. ثانیاً، به یک قطعه کد نیاز داریم که در زیر آمده است، که شامل پیاده سازی واقعی این سرویس است. یک سرویس می تواند ورودی ها و خروجی های متعددی داشته باشد، بنابراین ورودی به متد جاوا یک نقشه است، که به آن context می گویند، از نام های آرگومان به مقادیر آرگومان و خروجی را به صورت یک نقشه دیگر به نام results برمی گرداند. این روش سفارشی سازی چندسطحی از ارجاعات نرم مشابه مثال ایجاد نظرسنجی استفاده می کند. تفاوت اصلی
این است که ارجاع در اینجا بین مدل و کد است نه بین مدل ها. مزیت در این مورد این است که می توان از یک کتابخانه جاوای شخص ثالث برای ساخت PDF بهره برد. یک کاربرد معمول دیگر این است که از قطعه کدهای جاوا برای فراخوانی وب سرویس های خارجی استفاده شده و نتایج را در قالب مناسب وارد کنیم. مشکل هماهنگی این مثال برخی از مزایای استفاده از زبان های مختلف در توسعه را نشان می دهد. با این حال، مشکلاتی نیز با این نوع توسعه همراه است. این مشکلات ناشی از این است که هرچه تعداد بیشتری از مصنوعات را وارد فرآیند خود کنیم، نیاز به هماهنگی بیشتر بین تلاش های توسعه دهنده داریم. ما این مشکلات را به عنوان مشکل هماهنگی ارجاع خواهیم داد. مشکل هماهنگی جنبه مفهومی و فنی دارد. از نظر مفهومی، مشکل اصلی این است که زبان های مختلف و تعامل آنها را درک کنیم. برای طراحی و هماهنگی صحیح مدل ها در زبان های مختلف، توسعه دهندگان باید درک کافی از نحوه تعامل زبان ها داشته باشند. از نظر فنی، مشکل اصلی این است که انطباق را اعمال کنیم. ابزارها باید برای شناسایی ناسازگاری ها در زمان مدل سازی و کمک به توسعه دهندگان برای حل این ناسازگاری ها فراهم شوند. در ادامه
، این دو جنبه را با جزئیات بیشتری بررسی خواهیم کرد. هماهنگی به عنوان یک چالش مفهومی اولین مشکلی که توسعه دهندگان هنگام شروع به توسعه با زبان های مختلف با آن روبه رو می شوند، کافوفونی زبان ها است. یادگیری زبان های مختلف و درک تعامل آنها برای درک ترکیب پیچیده مصنوعات ضروری است. به عنوان مثال، فریم ورک OFBiz هفده زبان مختلف دارد و بیش از 200,000 خط کد زبان خاص دامنه، بنابراین پیچیدگی می تواند بسیار زیاد باشد! در حال حاضر هیچ روش شناخته شده ای برای مشخص کردن زبان های مختلف وجود ندارد که توسعه دهندگان بتوانند به سرعت به درک عملیاتی دست یابند. ابزارها در اینجا به عنوان یک مکانیزم خودجوش برای یادگیری و کاوش اهمیت دارند زیرا توسعه دهندگان معمولاً از ابزارها برای یادگیری از طریق آزمایش ها استفاده می کنند. به ویژه سه زمینه وجود دارد که ابزارها برای مدل های خاص دامنه مفید هستند: 1. درک یک زبان 2. درک تعامل زبان ها 3. درک نحوه استفاده از زبان ها اولاً، درک یک زبان می تواند دشوار باشد و در مورد زبان های خاص دامنه مبتنی بر XML، یک اعتراض رایج و شهودی این است که «نحو اهمیت دارد». این استدلال می تواند به صورت زیر بیان شود: «
زبان های مختلف سخت به فهم هستند و تنها باعث سردرگمی می شوند زیرا نحو مبتنی بر XML آن ها به ویژه پرجزئیات و غیرقابل فهم است. استفاده از یک زبان عمومی مانند جاوا بهتر خواهد بود زیرا در آن صورت توسعه دهندگان می توانند از نحو ای که قبلاً می شناسند استفاده کنند». در حالی که این اعتراض قطعاً مهم است، اما نکته مرکزی را از دست می دهد. XML یا یک فرمت مشابه ممکن است نحوی نباشد که توسعه دهندگان در واقع با آن کار می کنند. یکی از مزایای استفاده از زبان های خاص دامنه مبتنی بر XML این است که می توانیم ویرایشگرهای خاص دامنه ارائه دهیم. شکل زیر نشان می دهد که یک ویرایشگر فرضی برای Entity DSL چگونه ممکن است به نظر برسد. این ویرایشگر دامنه را به صورت ساده و جذاب بصری ارائه می دهد اما ممکن است از نمایش XML (و شاید یک پیکربندی طراحی) در پشت صحنه استفاده کند. دقیقاً همان طور که ممکن است شکایت کنیم که XML انتخاب بدی است، می توانیم اعتراض کنیم که زبان عمومی مانند جاوا برای برخی از وظایف انتخاب بدی است. علاوه بر این، توسعه دهندگان ممکن است کمتر از ویرایشگر در شکل نسبت به کد XML یا جاوا ترس داشته باشند. اگر قبول کنیم که نحو اهمیت دارد
، استفاده از زبان های مختلف با ویرایشگرهای اختصاصی یک استراتژی منطقی می شود. سادگی ویرایشگر باعث می شود که زبان آسان تر درک شود و بنابراین راحت تر استفاده شود. به عبارت دیگر، اعتراض به اهمیت نحو ممکن است دقیقاً دلیلی باشد که ما به دنبال کاوش در زمینه زبان های خاص دامنه هستیم. ثانیاً، تعاملات زبان ها روابط بین زبان ها را آشکار می کند. توسعه دهندگان باید قادر باشند بین عناصر مرتبط در مصنوعات مختلف جابجا شوند. سهولت ناوبری بین مصنوعات مختلف نرم افزاری یک معیار مهم برای ابزارها در محیط های توسعه سنتی است. اگرچه در این زمینه مطالعات تجربی انجام نداده ایم، اما فرض می کنیم که تسهیلات ناوبری مناسب بهره وری را افزایش می دهد. این ادعا با مشاهده ای که در حال حاضر تمام محیط های توسعه اصلی امکانات ناوبری پیشرفته ای مانند مرورگر سلسله مراتب نوع یا توانایی جستجو و پرش به ارجاعات به تعریف یک متد را ارائه می دهند، پشتیبانی می شود. محیط های توسعه می توانند این امکانات ناوبری را فراهم کنند زیرا آن ها یک مدل به روز از فایل های منبع را به صورت درخت نحو انتزاعی نگهداری می کنند. در یک محیط توسعه با چندین زبان، ناوبری بسیار دشوارتر
است. محیط های موجود برای تجزیه و نمایش مدل های DSL به صورت درخت نحو انتزاعی برای زبان های دلخواه و شاید حتی زبان های خاص برنامه مانند زبان های مثال قبلی طراحی نشده اند. علاوه بر این، بدون این نمایش داخلی، محیط های موجود نمی توانند ارجاعات درون زبان یا بین زبان را برای چنین زبان هایی حل کنند و بنابراین نمی توانند ناوبری مفیدی را فراهم کنند. این بدان معناست که توسعه دهندگان باید یک مدل مفهومی از نحوه ارتباط بخش های سیستم خود نگه دارند. از طرف دیگر، ابزارهای جدید با تسهیلات ناوبری که برای چندین زبان طراحی شده اند، در درک روابط بین زبان ها بسیار مفید خواهند بود. به عنوان مثال، این ابزارها باید روابط بین سه زبان را با استفاده از ارجاعات نرم به عنوان نقاط ناوبری نمایش دهند. سومین مورد، برای درک استفاده از زبان ها باید قادر باشیم عملیات ویرایش صحیح را از عملیات نادرست در محیط توسعه خود تمایز دهیم. محیط های توسعه سنتی مدت هاست که راهنمایی هایی در حین نوشتن برنامه ارائه داده اند. کامپایلر تدریجی به محیط اجازه می دهد تا پیشنهادات دقیقی به توسعه دهنده بدهد مانند اینکه چگونه یک عبارت را تکمیل کند. انواع دیگر راهنمایی های
مداخله گر نیز وجود دارد مانند ویرایشگرهای مبتنی بر نحو که تنها ورودی هایی که با گرامر سازگار هستند را می توان وارد کرد. ویرایشگرهای متنی عمومی که می توانند با گرامر یک زبان پارامتریک شوند، مدت هاست که وجود دارند. ویرایشگرهای موجود هنگام ارائه راهنمایی، روابط سازگاری بین زبان ها را در نظر نمی گیرند. در مثال قبلی، یک ویرایشگر ایده آل باید برای مثال قادر باشد سرویس createSurvey را به عنوان یک مقدار معتبر هنگام ویرایش ویژگی target در تعریف فرم پیشنهاد کند. محیطی که می تواند درباره مصنوعات از زبان های مختلف استدلال کند، همچنین قادر خواهد بود به توسعه دهنده کمک کند تا وضعیت های برنامه ای را شناسایی کند که در آن تطابق محلی وجود دارد اما تطابق جهانی نه. چنین وضعیتی زمانی ایجاد می شود که یک مدل به خوبی شکل گرفته است و بنابراین محلی سازگار است، اما در عین حال یک قید بین زبان را نقض می کند. راهنمایی یا کمک هوشمندانه به صورت پیشنهادهایی درباره نحوه تکمیل مدل برای محیط های با زبان های متعدد و محدودیت های پیچیده انطباق مفید خواهد بود. عملیات ویرایشی که توسط ابزارها پیشنهاد می شود، می تواند فرآیند یادگیری نحوه استفاده از ز
بان ها را برای توسعه دهنده آسان تر کند.
آسیاب چکشی ، فورج چکشی یا چکش کارگاهی در دوران پیش از صنعت بود که معمولاً برای تولید محصولات نیمه تمام، فرفورژه آهن یا گاهی اوقات ابزار تمام شده کشاورزی یا معدنی یا سلاح های نظامی استفاده می شد. ویژگی ای که نام خود را به این کارگاه ها داد، چکش سفری آب محور یا مجموعه ای از چکش ها بود که در این فرآیند استفاده می شد. شفت، یا "غلاف" چکش در وسط چرخانده می شود و سر چکش با عمل بادامک هایی که روی یک میل بادامک چرخان قرار می گیرد، بلند می شود که به طور دوره ای انتهای میل را فشار می دهد. با بالا و پایین رفتن، سر چکش یک قوس را توصیف کرد. رویه چکش برای دوام از آهن ساخته شده بود. آسیاب چکشی. این آسیاب ها که در اصل توسط چرخ های آب به حرکت در می آمدند، اما بعداً با نیروی بخار نیز به کار می رفتند، زیرا ابزارها با گذشت زمان سنگین تر شدند و در نتیجه ساخت دستی دشوارتر شد. آسیاب های چکشی سنگ آهن را با استفاده از زغال سنگ ذوب می کردند که اصطلاحاً بلومری می شد. در این کوره های ذوب، که مجهز به دم هایی بودند که توسط نیروی آب نیز هدایت می شد، سنگ معدن به صورت توده ای درخشان از آهن نرم، خام، سرباره سیال و بقایای زغال سنگ ذوب می شد. آه
ن مانند یک کوره بلند مدرن سیال نبود، اما عمدتاً به دلیل وجود سرباره مایع، یک توده خمیری و متخلخل باقی ماند. این توده های آهن اسفنجی که از نظر تاریخی به عنوان "شکوفه" شناخته می شوند، در ابتدا با دست و با استفاده از یک پتک فشرده می شوند. پس از آن، آنها را چندین بار، معمولاً با چکش سفر یا با پتک، جعل می کردند تا زمانی که سرباره و زغال آن از بین برود. برای آن، آهن را در کوره آهنگری یا کوره آهنگری دیگر گرم می کردند. سپس آهن می تواند مستقیماً به عنوان آهن نرم استفاده شود. نیازی به فرآیند بهبود بیشتر، مانند جریمه کاری که در عملیات کوره بلند استفاده می شود، نبود. سپس آهن میله ای درشت به دست آمده به صورت خارجی به عنوان مثال در کارهای مخصوص و کوچک چکش ( "Zainhammer" ) به میله های آهنی نازک (مثلاً سیم ضخیم)، به اصطلاح آهن میله ای ( "Zaineisen" )، که توسط میخ سازان برای تولید میخ مورد نیاز بود، کار می کرد. پردازش بیشتر به آهن تصفیه شده یا فولاد "الاستیک" برای مثال برای تیغه های شمشیر ، توسط آهنگرهای تخصصی چکش آهن تصفیه شده یا آهنگران در محل انجام شد. توزیع. از نظر جغرافیایی، آسیاب های چکشی به در دسترس بودن نیروی آب وابست