احسان رضایی http://www.developit.ir/ احسان رضایی، توسعه دهنده وب fa-IR دانشگاه یا موز!

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

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

/post/view?id=271 2017-05-09 16:53:29
دیتا تایپ مناسب برای فیلد status در پایگاه داده

گاهی داخل app نیاز به یک فیلد با مقادیر مشخصی داریم. مثل status در جدول payments که میتونه paid یا unpaid باشه. از اونجایی که در پروژه های مختلف این فیلد رو به روش های متفاوتی پیاده میکردن تصمیم گرفتم در موردش کمی بنویسم. به طور کلی سه دیتا تایپ برای این قبیل فیلد ها انتخاب میشن که در موردشون توضیح میدم.

- string/varchar: ساده ترین رویکرد انتخاب دیتا تایپ string هست. وضوح خوبی هم داره. چون هنگام توسعه با یک نگاه به سطر مورد نظرتون متوجه وضعیتش میشید. حتی میتونید توی فرانت دقیقا این رشته رو چاپ کنید(ولی نه توی app های چند زبانه). اما بسته به طول رشته طبیعتا فضایی برای ذخیره سازی در نظر گرفته میشه. هر چند موضوع فضا خیلی وقته به حاشیه رفته و کمتر کسی نگران پر شدن هارد سرورشه، اما اگر سطرهای زیادی داشته باشید هنگام پیمایش اطلاعات، کندی رو حس خواهید کرد. مورد بعدی تغییرات هست. فرض کنید پس از مدتی متوجه غلط املایی در یکی از آیتم ها میشید، تمام سطر ها باید update بشن.

- enum: چیزی که ازش به شدت متنفرم! من دوست ندارم منطق و فرآیند برنامه رو توی دیتابیس ببرم. چرا که مثلا هنگام تغییرات و یا کم و زیاد شدن آیتم ها مجبورم جدول رو هم بروز کنم.

- tinyint: یک رویکرد مناسب برای بهبود سرعت query ها و ملایم در هنگام تغییرات یا افزودن گزینه های بیشتر. نیازی نیست به طور مستقیم با اعداد کار کنید، میتویند از جدول میانی یا ثابت ها بهره برد. من به طور پیشفرض از ثابت ها برای آیتم های کم و جدول در مواقعی که گزینه های زیادی یاا اطلاعات اضافی مثل توضیحات و... داریم استفاده میکنم.

انتخاب هر یک از این روش ها بستگی به شرایط و app شما داره. میتونید string رو برای پروژه های کوچک و اطلاعات کم استفاده کنید. enum توی پروژه هایی که به شما ارث رسیده(یک پروژه قدیمی که مشغول توسعه نسخه جدیدش هستید) و فرآیند ها و منطق برنامه از قبل مشخص هست هزینه تغییرات پایینی داره. tinyint هم زمانی که در یک پروژه بزرگ یا مواقعی که تغییرات زیادی هنگام توسعه اتفاق میوفته کارآمد هست.

/post/view?id=356 2020-05-17 19:17:59
تشخیص و دسته بندی آگهی ها در جاب ترند

تصمیم گرفتم خیلی کوتاه در مورد تشخیص و دسته بندی آگهی های داخل جاب ترند توضیح بدم و بگم چرا اسم این فرآیند ها رو هوشمند گذاشتم و با تکه تکه کردن رشته ها(متن آگهی) یا جستجوی عبارت های خاص کار نمیکنه.
من از واژه برچسب استفاده میکنم. برچسب هر چیزی میتونه باشه. یک شغل، حرفه، نوع قرارداد و...
قبلا هم داخل توییتر چندبار گفتم فرآیند برچسب زنی رو دستی انجام نمیدم و با استفاده از کتابخانه های nlp این موضوع صورت میگیره. اگر بنا بود تا این حد جاب ترند دستی کار کنه یا باید چند نفر رو استخدام میکردم که بودجه اش رو نداشتم یا تک نفری چند سال آینده یک ابزار ضعیف رو ارائه میدادم و منتشر میکردم.

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

انجام این کار به صورت دستی امکان پذیر نیست.

/post/view?id=354 2020-02-26 13:13:38
استقرار وب اپلیکیشن golang با استفاده از docker-compose

برای deploy روش های زیادی وجود داره که اغلب وارد پیچیدگی هایی میشن. من تصمیم دارم کوتاه و ساده در موردش بنویسم و از تنظیمات جانبی اون صرف نظر میکنم.

در مرحله اول به یک http server نیاز داریم. من خودم مخالف استفاده از فریمورک های golang هستم ولی الان دم دسته و مثال رو با gin انجام میدم. شما هر طور خواستین بنویسید.

package main

import (
	"github.com/gin-gonic/gin"
	"net/http"
)

func main()  {
	router := gin.Default()
	router.GET("/", func(context *gin.Context) {
		context.JSON(http.StatusOK, gin.H{
			"status": "OK",
		})
	})

	router.Run(":8080")
}

به Dockerfile نیاز داریم. پیشفرض به پورت 8080 گوش میده و app رو اجرا میکنه(پورت http server هم روی 8080 ست شده).

FROM golang:1.13
ENV APP_NAME app
ENV PORT 8080
WORKDIR /go/src/app

CMD ./${APP_NAME}
EXPOSE ${PORT}
/post/view?id=353 2020-02-06 22:13:56
جستجو با استفاده از عبارت باقاعده(regex) در elasticsearch

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

مثال زیر اسنادی رو که فیلد user شون با k شروع و با y تموم بشه رو match میکنه.

GET /_search
{
    "query": {
        "regexp": {
            "user": {
                "value": "k.*y"
            }
        }
    }
}
/post/view?id=351 2020-01-31 20:55:31
تعریف و جستجو بر اساس الگو با استفاده از wildcard query در elasticsearch

با استفاده از wildcard query میتونید الگو های ساده ای برای matching تعریف کنید. wildcard از دو عملگر پشتیبانی میکنه.

? : یک کاراکتر تکی رو match میکنه.

* : صفر یا بیشتر. هر تعداد کاراکترُ match میکنه.

مثال زیر اسنادی رو پیدا میکنه که نویسنده هاشون با حرف t شروع شده باشن.

GET /_search
{
    "query": {
        "wildcard": {
            "authors": {
                "value": "t*"
            }
        }
    }
}
/post/view?id=350 2020-01-30 23:55:45
پرس و جو های ترکیبی با استفاده از boolean query در elasticsearch

قبلا در مورد جستجوی ساده نوشتم. توی این مطلب میخواییم ببینیم چطور برای جستجو از عملگر های and، or و not در query استفاده کنیم. boolean query این قابلیت رو به ما میده. باهاش query های مرکب/ترکیبی مینویسیم. این پرس و جوی مرکب شامل must، filter، should و must_not میشه.

- must: برای matching یا تطابق در اسناد استفاده میشه. و روی score_ تاثیر میذاره که توی مطالب قبلی در موردش توضیح دادم. برابر با AND

- filter: برای فیلتر اسناد هست و روی score_ تاثیر نداره.

- should: مواردی رو درش قرار میدیم که میخواییم در اسناد وجود داشته باشه. برابر با OR

- must_not: برعکس must، مواردی که در این بخش تعریف میکنیم نباید در اسناد وجود داشته باشن. اینم میشه گفت یه مدل فیلتر هست و معادل عملگر NOT

/post/view?id=349 2020-01-22 23:09:16
معنی و مفهوم query و filter در elasticsearch

توی مطالب قبلی هنگام ارسال درخواست و در قسمت body از عبارت query برای جستجوهامون استفاده کردیم.

{
  ...
    "multi_match": {
      "query": "guide"
    }
  ...
}

در واقع query به این سوال پاسخ میده: چقدر اسناد موجود با مقدار query(در اینجا guide) مطابقت داره. الستیک سرچ میزان این مطابقت رو در خروجی درخواست و متا فیلد score_ محاسبه میکنه و قرار میده. مرتب سازی/sort خروجی هم بر همین اساس و معیاره.

/post/view?id=348 2020-01-01 00:37:10
اولویت دهی برای جستجو یا boosting در elasticsearch

توی مطلب قبلی در مورد تفاوت match و multi_match توضیح دادم. معمولا هنگام جستجو و استفاده از multi_match بهتره اولویت های بالاتر یا پایین تری برای فیلد هامون در نظر بگیریم. به طور پیشفرض الستیک سرچ هنگام جستجو و match کردن بین فیلد ها تفاوتی قائل نمیشه. الستیک معیاری به نام boost داره که مقدار اولیه اش 1.0 هست و شما میتونید با افزایش این مقدار به فیلدهاتون برای match شدن اولویت بدین.

مثلا یک document با دو فیلد title و content رو در نظر بگیرید. میخواییم هنگام جستجو اولویت title برای match شدن دو برابر content باشه. چون از نظر ما title مهمتره و اگر بتونیم در title چیزی پیدا کنیم به احتمال خیلی زیاد نتیجه جستجوی بهتری خواهیم داشت.

برای boosting یا اولویت دادن دو راه وجود داره. هنگام تعریف mappings یا زمان جستجو. اگر سیاست های جستجوی ما مشخص باشه بهتره داخل mapping این کار انجام بشه.

/post/view?id=347 2019-12-29 23:32:05
قابلیت جستجوی کثیف یا درهم(fuzzy query) در elasticsearch

توی مطلب قبلی در مورد جستجوی ساده و پایه در الستیک سرچ نوشتم. برای همه ی ما اتفاق افتاده عمدی یا غیر عمدی داخل گوگل چیز اشتباهی رو جستجو کردیم و خودش توضیح داده آیا منظورت فلان مورد بود؟ حقیقتا گوگل تشخیص میده ما اشتباه نوشتیم و اون رو بهمون  گوشزد میکنه. بیایید اسم این مدل جستجو رو بذاریم جستجوی کثیف یا درهم. اتفاقا الستیک هم چنین قابلیتی رو بهمون میده و خوشبختانه برای فارسی هم به خوبی کار میکنه :)
خب برای جستجوی کثیف چکار باید کرد؟ ما توی این مدل کوئری که خود استیک بهش fuzzy query میگه به جای multi_match یا match از fuzzy استفاده میکنیم! به همین راحتی :)

fuzzy query مواردی که مشابه و نزدیک مورد جستجوی ماست رو هم match میکنه. برای اینکار fuzzy همه ی حالت های ممکن رو بررسی میکنه و نتایجی که بیشترین مطابقت رو دارنُ برمیگردونه. این نکته رو گفتم که بدونید مثل جستجو های ساده کم هزینه نیست و در جای مناسب نه همه جا ازش استفده کنید. مثلا گوگل نمیاد توی اسنادش fuzzy search کنه. اون عبارت جستجوی شما رو fuzzy search میکنه تا برای جستجوی دقیق اصلاحش کنید.

/post/view?id=346 2019-12-28 20:34:32
جستجوی ساده یا basic match در elasticsearch

اولین مطلب در مورد کوئری های جستجو در elasticsearch رو با ساده ترین روش یا به عبارتی basic match شروع میکنم. دو روش برای match کردن یا جستجو وجود داره. روش اول از طریق پارامتر داخل  url هست و روش دوم ارسال query در body درخواست/request.

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

مثال: جستجوی guide در ایندکس developit_ir. کلمه guide در تمام فیلد ها جستجو میشه.

GET /developit_ir/_search?q=guide

نمونه خروجی:

"hits": [
{
  "_index": "developit_ir",
  "_type": "_doc",
  "_id": "1",
  "_score": 3.541,
  "_source": {
    "title": "developit.ir",
    "authors": [
      "ehsan rezaei"
    ],
    "summary": "elasticsearch guide :)",
    "publish_date": "2020-01-01"
  }
}
]
/post/view?id=345 2019-12-28 20:11:46
چرا به وب فریمورک های golang نیازی نیست؟

golang-web-freamework
زمانی که golang رو شروع کردم بلافاصله مشغول تحقیق و بررسی وب فریمورک هاش بودم. من قبلا مطلبی در مورد استفاده از فریمورک نوشتم و هنوز هم بر این عقیدم که مزیت های استفاده از فریمورک نسبت به عیب هایی که داره بیشتره. نکته جالب این بود که اغلب مخالف استفاده از فریمورک در go بودن و خب معمولا به جمله ی نیازی بهشون نداری بسنده میکردن.

برای تجربه بیشتر سراغ سه فریمورک gin، echo و روم به دیوار iris رفتم! یه نکته ی خیلی مهم وجود داشت. به نظرم این فریمورک ها به اندازه کافی کامل نیستن و هنگام توسعه زیاد اتفاق میوفته از پکیج های خارجی استفاده کنید. حقیقتا برای validator، router، middleware و error handling که میتونی پکیج هاشُ خودت توی پروژه ات به سادگی اضافه و استفاده کنی، نیازی به فریمورک نداری. در نتیجه تقریبا مزیتی نخواهد موند که از عیب هاش بیشتر باشه. اما پیشنهاد میکنم فریمورک هاشُ برای تجربه هم که شده امتحان کنید.

/post/view?id=344 2019-11-30 00:22:14
عدم موفقیت پروژه های نرم افزاری قسمت اول

fail

اجازه بدین قبل از شروع این موضوع آماریُ خدمتتون ارائه بدم.

در سال 2016 تخمین زده شد حدود 21 میلیون توسعه دهنده حرفه ای نرم افزار در سراسر دنیا فعالیت میکنن. با این حال:

75 درصد مدیران فناوری پیش بینی میکنن پروژه های نرم افزاری اونها شکست میخوره.

- در پروژه های موفق، کمتر از یک سوم اونها با بودجه و زمان مشخص شده به پایان میرسن.

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

1) داشتن شور، اشتیاق، امید و انگیزه. اما تخصص نه!

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

/post/view?id=343 2019-09-30 17:55:10
شبکه اجتماعی کتاب در گردش

عادت دارم وقتی شروع به یادگیری زبان برنامه نویسی یا فریمورک جدید میکنم یک پروژه هم باهاش به اجرا در میارم(تازگیا اوپن سورس). با فریمورک جدید(که اصلا براتون مهم نباشه چی هست!) به نظرم رسید موضوع کتاب در گردش یا Book Crossing رو انجام بدم. حالا کامل و یا بخشی ازش پیاده بشه و داستان از این قراره که کاربران این شبکه میتونن کتاب هایی که مطالعه کردنُ به اشتراک بذارن. اگر رایگان بود همراه با قابلیت مشاهده/مطالعه و اگر غیر رایگان، لینک خرید و سپس مشاهده.

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

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

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

البته احتمال وجود برنامه مشابه این طرح وجود داره. این رو هم باید در نظر بگیریم.

و مهمتر از همه، خوشحال میشم نظرتون در مورد این موضوع رو بخونم :)

تکمیلی.

میتونید روند توسعه این پروژه رو داخل github ببینید.

https://github.com/rezaei121/bookcrossing
/post/view?id=342 2019-09-26 00:45:11
نصب افزونه twig در yii2

سلام. صدای من رو از رسپینا نسخه 3 میشنوید :دی

این نسخه رو با نصب افزونه twig در Yii2 افتتاح میکنیم. هر چند من زیاد با template engine موافق نیستم و فکر میکنم مناسب پروژه های کوچیک نیست و صرفه زمانی و اقتصادی نداره. ولی خب به هر حال گاهی وجودش لازمه.

نصب.

دستور زیرُ اجرا کنید:

php composer.phar require --prefer-dist yiisoft/yii2-twig

یا توی فایل کامپوزر قرارش بدین:

"yiisoft/yii2-twig": "~2.0.0"
/post/view?id=341 2019-09-24 23:56:22
چپ دست ها آدمای خاصی هستن یا چی؟

left hand


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

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

و البته دردسر! موردی که کمتر بهش اشاره شده. توجه داشته باشین که بسیاری از ابزارها برای افراد راست دست طراحی شده. مثلا خود من با دکمه ی روشن و خاموش ماشین ریش تراشم مشکل دارم و باید از دست راستم برای استفاده اش کمک بگیرم.

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

یادمه این موضوع چپ دست بودن رو به نیم کره های مغز هم ربط میدادن که توجه تون رو به این نقل قول جلب میکنم:

در مطالعه‌ای در سال ۲۰۱۳، تصاویر سه‌بعدی مغز هزار نفر مورد بررسی قرار گرفت و با استفاده از اسکنر MRI، میزان فعالیت هردو نیمکره اندازه‌گیری شد. نتایج نشان می‌داد که هر انسان، از هردو نیمکره مغزی خود بهره می‌برد و بخشی بر دیگری غالب نیست.

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

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

/post/view?id=338 2019-08-14 22:09:06
این جماعت توسعه دهنده ی خرده گیر

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

آیا واقعا جای عیب و ایراد گرفتن وجود داره؟ بله. حتما اینطور هست و اتفاقا کار آسونیه :)

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

موضوع دقیقا اینجا مشخص میشه. ممکن هست انتخاب یک شخص برای من نوعی و یا شخص دیگه ای سم باشه!

عمدتا 4 دلیل اصلی برای این موضوع وجود داره.

اول. بزرگ جلوه دادن خودشون!

طرف مقابل با ایراد گرفتن و گاها مسخره کردن به دنبال بزرگ جلوه دادن خودشه. مثل سیگار که نوجوون ها با گذاشتنش گوشه ی لب حس بزرگی بهشون دست میده. توی برنامه نویسی هم همینطوره. مثلا میتونی بگی فلان زبان برنامه نویسی آشغاله تا بگن wow چه برنامه نویس خفنی و از این جور حرف ها. جالب اینجاست که اغلب نظراتشون پشتوانه و دلیل و مدرک نداره. اصلا دنبال اون موضوعی که در موردش ایراد میگیرن نرفتن و بیشتر حرف های دیگرانُ تکرار میکنن.

دوم. سلیقه...

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

هیچ قانون سختگیرانه ای برای شما وجود نداره...

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

سوم. جبهه گرفتن.

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

چهارم. اطلاعات کهنه.

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

 

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

اما اگر به اون 4 دسته از توسعه دهندگان بالا برخوردین هدفونتون رو بذارید گوشتون و با هر چیزی که خوشحالتون میکنه کار کنید. از افرادی که این مسائل ساده رو درک نمیکنن نمیشه توقع ساکت شدن داشت.

/post/view?id=335 2019-05-28 15:05:47
تفاوت بین Active Record و Data Mapper

هنگامی که موضوع کار با داده ها در application مطرح میشه احتمالا نیاز به یک ORM پیدا خواهید کرد. ORM یک لایه بین پایگاه داده و application شماست. که به وسیله اون عملیات CRUD یا به عبارت دیگه create, read, update,  delete به آسونی انجام میپذیره. بیشتر از این به ORM نمیپردازم چون در حال حاضر اکثر فریمورک های مدرن ازش استفاده میکنن و بعید میدونم شما تا الان با اون کار نکرده باشید.

دو الگو پیاده سازی محبوب ORM ها Active Record و Data Mapper هست. در این مقاله تصمیم دارم به تفاوت بین این دو الگو بپردازم. مزایا و معایبشون چی هست و چطور میشه یکی از این الگو ها رو برای کار خودمون انتخاب کنیم.

/post/view?id=334 2019-05-26 16:44:15
درس های yii2 شماره 25: ایجاد خودکار migration از روی پایگاه داده

بیشتر به درد اونایی میخوره که وسط کار یاد migration افتادن. زمانی که دیتابیس رو طراحی کردن و آماده است. یا کسایی که حال و حوصله ی migration نوشتن رو ندارن.

برای این کار(ایجاد خودکار migration از روی پایگاه داده) در درجه اول نیاز به PHP >= 7.1 و Yii >= 2.0.15.1 دارید. داخل composer.json بسته bizley/migration رو اضافه و بروزرسانی کنید.

{
    "require": {
        "bizley/migration": "~3.0.0"
    }
}

برای PHP < 7.1 میتونید از نسخه ی 2.3.0 این بسته استفاده کنید.

{
    "require": {
        "bizley/migration": "~2.3.0"
    }
}

قدم بعدی پیکره بندی هست. ترجیحا داخل پیکره بندی console این کارُ انجام بدین.

'components' => [
    // ...
],
'controllerMap' => [
    'migration' => [
        'class' => 'bizley\migration\controllers\MigrationController',
    ],
],

 

/post/view?id=332 2019-04-19 20:04:15
مدل سازی داده و طراحی پایگاه داده چند زبانه

Multiple Languages

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

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

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

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

/post/view?id=331 2019-04-12 16:33:48