ಕೈಗಾರಿಕಾ ಯಂತ್ರ ಕಲಿಕೆ: 10 ವಿನ್ಯಾಸ ತತ್ವಗಳು

ಕೈಗಾರಿಕಾ ಯಂತ್ರ ಕಲಿಕೆ: 10 ವಿನ್ಯಾಸ ತತ್ವಗಳು

ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ಹೊಸ ಸೇವೆಗಳು, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಇತರ ಪ್ರಮುಖ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಪ್ರತಿದಿನ ರಚಿಸಲಾಗುತ್ತದೆ, ಅದು ನಂಬಲಾಗದ ವಿಷಯಗಳನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ: SpaceX ರಾಕೆಟ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವ ಸಾಫ್ಟ್‌ವೇರ್‌ನಿಂದ ಹಿಡಿದು ಮುಂದಿನ ಕೋಣೆಯಲ್ಲಿನ ಕೆಟಲ್‌ನೊಂದಿಗೆ ಸ್ಮಾರ್ಟ್‌ಫೋನ್ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುವವರೆಗೆ.

ಮತ್ತು, ಕೆಲವೊಮ್ಮೆ, ಪ್ರತಿ ಅನನುಭವಿ ಪ್ರೋಗ್ರಾಮರ್, ಅವರು ಭಾವೋದ್ರಿಕ್ತ ಆರಂಭಿಕ ಅಥವಾ ಸಾಮಾನ್ಯ ಫುಲ್ ಸ್ಟಾಕ್ ಅಥವಾ ಡೇಟಾ ಸೈಂಟಿಸ್ಟ್ ಆಗಿರಲಿ, ಬೇಗ ಅಥವಾ ನಂತರ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮತ್ತು ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುವ ಸಾಫ್ಟ್‌ವೇರ್ ರಚಿಸಲು ಕೆಲವು ನಿಯಮಗಳಿವೆ ಎಂದು ಅರಿತುಕೊಳ್ಳುತ್ತಾರೆ.

ಈ ಲೇಖನದಲ್ಲಿ, 10 ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್ ವಿಧಾನದ ಆಧಾರದ ಮೇಲೆ, ಅದನ್ನು ಸುಲಭವಾಗಿ ಅಪ್ಲಿಕೇಶನ್/ಸೇವೆಗೆ ಸಂಯೋಜಿಸಲು ಕೈಗಾರಿಕಾ ಯಂತ್ರ ಕಲಿಕೆಯನ್ನು ಹೇಗೆ ಪ್ರೋಗ್ರಾಂ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು 12 ತತ್ವಗಳನ್ನು ನಾನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ. Heroku ತಂಡವು ಸೂಚಿಸಿದೆ. ಈ ತಂತ್ರದ ಅರಿವನ್ನು ಹೆಚ್ಚಿಸುವುದು ನನ್ನ ಉಪಕ್ರಮವಾಗಿದೆ, ಇದು ಅನೇಕ ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಡೇಟಾ ಸೈನ್ಸ್ ಜನರಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಈ ಲೇಖನವು ಕೈಗಾರಿಕಾ ಯಂತ್ರ ಕಲಿಕೆಯ ಕುರಿತು ಲೇಖನಗಳ ಸರಣಿಗೆ ಮುನ್ನುಡಿಯಾಗಿದೆ. ಅವುಗಳಲ್ಲಿ ನಾನು ನಿಜವಾಗಿ ಮಾದರಿಯನ್ನು ಹೇಗೆ ತಯಾರಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ಪ್ರಾರಂಭಿಸುವುದು, ಅದಕ್ಕಾಗಿ API ಅನ್ನು ರಚಿಸುವುದು, ಹಾಗೆಯೇ ವಿವಿಧ ಪ್ರದೇಶಗಳು ಮತ್ತು ಕಂಪನಿಗಳ ಉದಾಹರಣೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ.

ತತ್ವ 1: ಒಂದು ಕೋಡ್ ಬೇಸ್

ಕೆಲವು ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಮೊದಲ ಹಂತಗಳಲ್ಲಿ, ಅದನ್ನು ಕಂಡುಹಿಡಿಯುವ ಸೋಮಾರಿತನದಿಂದ (ಅಥವಾ ತಮ್ಮದೇ ಆದ ಕಾರಣಕ್ಕಾಗಿ), Git ಅನ್ನು ಮರೆತುಬಿಡುತ್ತಾರೆ. ಅವರು ಪದವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರೆತುಬಿಡುತ್ತಾರೆ, ಅಂದರೆ, ಅವರು ಡ್ರೈವ್‌ನಲ್ಲಿ ಫೈಲ್‌ಗಳನ್ನು ಪರಸ್ಪರ ಎಸೆಯುತ್ತಾರೆ / ಪಠ್ಯವನ್ನು ಎಸೆಯುತ್ತಾರೆ / ಪಾರಿವಾಳಗಳಿಂದ ಕಳುಹಿಸುತ್ತಾರೆ, ಅಥವಾ ಅವರು ತಮ್ಮ ಕೆಲಸದ ಹರಿವಿನ ಬಗ್ಗೆ ಯೋಚಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನು ತಮ್ಮದೇ ಆದ ಶಾಖೆಗೆ ಒಪ್ಪಿಸುತ್ತಾರೆ, ಮತ್ತು ನಂತರ ಮಾಸ್ಟರ್.

ಈ ತತ್ವವು ಹೇಳುತ್ತದೆ: ಒಂದು ಕೋಡ್ಬೇಸ್ ಮತ್ತು ಅನೇಕ ನಿಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದೆ.

Git ಅನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಮತ್ತು ಸಂಶೋಧನೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ (R&D) ಬಳಸಬಹುದು, ಇದರಲ್ಲಿ ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ.

ಉದಾಹರಣೆಗೆ, R&D ಹಂತದಲ್ಲಿ ನೀವು ವಿಭಿನ್ನ ಡೇಟಾ ಸಂಸ್ಕರಣಾ ವಿಧಾನಗಳು ಮತ್ತು ಮಾದರಿಗಳೊಂದಿಗೆ ಕಮಿಟ್‌ಗಳನ್ನು ಬಿಡಬಹುದು, ನಂತರ ಉತ್ತಮವಾದದನ್ನು ಆಯ್ಕೆ ಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅದರೊಂದಿಗೆ ಸುಲಭವಾಗಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು.

ಎರಡನೆಯದಾಗಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಇದು ಭರಿಸಲಾಗದ ವಿಷಯವಾಗಿದೆ - ನಿಮ್ಮ ಕೋಡ್ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನಿರಂತರವಾಗಿ ನೋಡಬೇಕು ಮತ್ತು ಯಾವ ಮಾದರಿಯು ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಿತು, ಯಾವ ಕೋಡ್ ಕೊನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಲು ಅಥವಾ ತಪ್ಪಾದ ಫಲಿತಾಂಶಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಏನಾಯಿತು ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕು. . ಅದಕ್ಕಾಗಿಯೇ ಬದ್ಧತೆಗಳು!

ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸಹ ನೀವು ರಚಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಜೆಮ್‌ಫ್ಯೂರಿಯಲ್ಲಿ ಇರಿಸಬಹುದು, ಮತ್ತು ನಂತರ ಇತರ ಯೋಜನೆಗಳಿಗೆ ಅದರಿಂದ ಕಾರ್ಯಗಳನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳಬಹುದು, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು 1000 ಬಾರಿ ಪುನಃ ಬರೆಯಬಾರದು, ಆದರೆ ನಂತರ ಇನ್ನಷ್ಟು.

ತತ್ವ 2: ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಘೋಷಿಸಿ ಮತ್ತು ಪ್ರತ್ಯೇಕಿಸಿ

ಪ್ರತಿಯೊಂದು ಯೋಜನೆಯು ವಿವಿಧ ಗ್ರಂಥಾಲಯಗಳನ್ನು ಹೊಂದಿದ್ದು, ಅವುಗಳನ್ನು ಎಲ್ಲೋ ಅನ್ವಯಿಸಲು ನೀವು ಹೊರಗಿನಿಂದ ಆಮದು ಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಅದು ಪೈಥಾನ್ ಲೈಬ್ರರಿಗಳು, ಅಥವಾ ವಿವಿಧ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಇತರ ಭಾಷೆಗಳ ಗ್ರಂಥಾಲಯಗಳು ಅಥವಾ ಸಿಸ್ಟಮ್ ಪರಿಕರಗಳು - ನಿಮ್ಮ ಕಾರ್ಯ:

• ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಘೋಷಿಸಿ, ಅಂದರೆ, ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಎಲ್ಲಾ ಲೈಬ್ರರಿಗಳು, ಪರಿಕರಗಳು ಮತ್ತು ಅವುಗಳ ಆವೃತ್ತಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಫೈಲ್ ಮತ್ತು ಅದನ್ನು ಸ್ಥಾಪಿಸಬೇಕು (ಉದಾಹರಣೆಗೆ, ಪೈಥಾನ್‌ನಲ್ಲಿ ಇದನ್ನು Pipfile ಅಥವಾ requirements.txt ಬಳಸಿ ಮಾಡಬಹುದು. A ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅನುಮತಿಸುವ ಲಿಂಕ್: realpython.com/pipenv-guide)
• ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಂಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಅವಲಂಬನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ನೀವು ನಿರಂತರವಾಗಿ ಆವೃತ್ತಿಗಳನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, Tensorflow?

ಈ ರೀತಿಯಾಗಿ, ಭವಿಷ್ಯದಲ್ಲಿ ನಿಮ್ಮ ತಂಡವನ್ನು ಸೇರುವ ಡೆವಲಪರ್‌ಗಳು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಲೈಬ್ರರಿಗಳು ಮತ್ತು ಅವುಗಳ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ತ್ವರಿತವಾಗಿ ಪರಿಚಿತರಾಗಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಸ್ಥಾಪಿಸಲಾದ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಲೈಬ್ರರಿಗಳನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅವಕಾಶವಿದೆ. ಯೋಜನೆ, ಇದು ಗ್ರಂಥಾಲಯಗಳು ಅಥವಾ ಅವುಗಳ ಆವೃತ್ತಿಗಳ ಅಸಾಮರಸ್ಯವನ್ನು ತಪ್ಪಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ದಿಷ್ಟ OS ನಲ್ಲಿ ಸ್ಥಾಪಿಸಬಹುದಾದ ಸಿಸ್ಟಮ್ ಪರಿಕರಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಬಾರದು. ಈ ಪರಿಕರಗಳನ್ನು ಸಹ ಅವಲಂಬನೆಗಳ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ಘೋಷಿಸಬೇಕು. ಪರಿಕರಗಳ ಆವೃತ್ತಿಯು (ಹಾಗೆಯೇ ಅವುಗಳ ಲಭ್ಯತೆ) ನಿರ್ದಿಷ್ಟ OS ನ ಸಿಸ್ಟಮ್ ಪರಿಕರಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗದ ಸಂದರ್ಭಗಳನ್ನು ತಪ್ಪಿಸಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ.

ಹೀಗಾಗಿ, ಕರ್ಲ್ ಅನ್ನು ಬಹುತೇಕ ಎಲ್ಲಾ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ ಬಳಸಬಹುದಾದರೂ ಸಹ, ನೀವು ಅದನ್ನು ಅವಲಂಬನೆಗಳಲ್ಲಿ ಘೋಷಿಸಬೇಕು, ಏಕೆಂದರೆ ಇನ್ನೊಂದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ವಲಸೆ ಹೋಗುವಾಗ ಅದು ಇಲ್ಲದಿರಬಹುದು ಅಥವಾ ಆವೃತ್ತಿಯು ನಿಮಗೆ ಮೂಲತಃ ಬೇಕಾಗಿರುವುದಿಲ್ಲ.

ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ requirements.txt ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

ತತ್ವ 3: ಸಂರಚನೆಗಳು

AWS ನಿಂದ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಮತ್ತು ಇತರ ಕೀಗಳೊಂದಿಗೆ ಸಾರ್ವಜನಿಕ ರೆಪೊಸಿಟರಿಗಳಿಗೆ GitHub ಗೆ ಆಕಸ್ಮಿಕವಾಗಿ ಕೋಡ್ ಅನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವ ವಿವಿಧ ಡೆವಲಪರ್ ಹುಡುಗರ ಕಥೆಗಳನ್ನು ಅನೇಕರು ಕೇಳಿದ್ದಾರೆ, ಮರುದಿನ $6000 ಅಥವಾ $50000 ಸಾಲದೊಂದಿಗೆ ಎಚ್ಚರಗೊಳ್ಳುತ್ತಾರೆ.

ಸಹಜವಾಗಿ, ಈ ಪ್ರಕರಣಗಳು ವಿಪರೀತವಾಗಿವೆ, ಆದರೆ ಬಹಳ ಮಹತ್ವದ್ದಾಗಿವೆ. ಕೋಡ್ ಒಳಗೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಅಗತ್ಯವಿರುವ ನಿಮ್ಮ ರುಜುವಾತುಗಳನ್ನು ಅಥವಾ ಇತರ ಡೇಟಾವನ್ನು ನೀವು ಸಂಗ್ರಹಿಸಿದರೆ, ನೀವು ತಪ್ಪು ಮಾಡುತ್ತಿದ್ದೀರಿ ಮತ್ತು ಏಕೆ ಎಂದು ವಿವರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಪರಿಸರದ ಅಸ್ಥಿರಗಳಲ್ಲಿ ಸಂರಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಇದಕ್ಕೆ ಪರ್ಯಾಯವಾಗಿದೆ. ಪರಿಸರ ಅಸ್ಥಿರಗಳ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು ಇಲ್ಲಿ.

ಪರಿಸರದ ಅಸ್ಥಿರಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಗ್ರಹಿಸಲಾದ ಡೇಟಾದ ಉದಾಹರಣೆಗಳು:

• ಡೊಮೇನ್ ಹೆಸರುಗಳು
• API URL ಗಳು/URI ಗಳು
• ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ ಕೀಲಿಗಳು
• ಸಂಪರ್ಕಗಳು (ಮೇಲ್, ಫೋನ್, ಇತ್ಯಾದಿ)

ಈ ರೀತಿಯಾಗಿ ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ವೇರಿಯೇಬಲ್‌ಗಳು ಬದಲಾದರೆ ನೀವು ನಿರಂತರವಾಗಿ ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿಲ್ಲ. ಇದು ನಿಮ್ಮ ಸಮಯ, ಶ್ರಮ ಮತ್ತು ಹಣವನ್ನು ಉಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಉದಾಹರಣೆಗೆ, ನೀವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು Kaggle API ಅನ್ನು ಬಳಸಿದರೆ (ಉದಾಹರಣೆಗೆ, ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಮಾದರಿಯು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಲು ಅದರ ಮೂಲಕ ಮಾದರಿಯನ್ನು ರನ್ ಮಾಡಿ), ನಂತರ Kaggle ನಿಂದ ಖಾಸಗಿ ಕೀಗಳಾದ KAGGLE_USERNAME ಮತ್ತು KAGGLE_KEY, ಆಗಿರಬೇಕು ಪರಿಸರದ ಅಸ್ಥಿರಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.

ತತ್ವ 4: ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳು

ಕೋಡ್ ವಿಷಯದಲ್ಲಿ ಸ್ಥಳೀಯ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳ ನಡುವೆ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲದ ರೀತಿಯಲ್ಲಿ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ರಚಿಸುವುದು ಇಲ್ಲಿ ಕಲ್ಪನೆಯಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಸ್ಥಳೀಯ MySQL ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಗಳೆರಡನ್ನೂ ಸಂಪರ್ಕಿಸಬಹುದು. Google ನಕ್ಷೆಗಳು ಅಥವಾ Twitter API ನಂತಹ ವಿವಿಧ API ಗಳಿಗೂ ಇದು ಹೋಗುತ್ತದೆ.

ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಅಥವಾ ಇನ್ನೊಂದನ್ನು ಸಂಪರ್ಕಿಸಲು, ನೀವು ಮೇಲಿನ ಪ್ಯಾರಾಗ್ರಾಫ್‌ನಲ್ಲಿ ಮಾತನಾಡಿದ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳಲ್ಲಿನ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಕೀಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ.

ಆದ್ದರಿಂದ, ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ಬಾರಿ ಕೋಡ್‌ನೊಳಗೆ ಡೇಟಾಸೆಟ್‌ಗಳೊಂದಿಗೆ ಫೈಲ್‌ಗಳಿಗೆ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುವ ಬದಲು, ಪಾಥ್‌ಲಿಬ್ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುವುದು ಉತ್ತಮ ಮತ್ತು config.py ನಲ್ಲಿ ಡೇಟಾಸೆಟ್‌ಗಳಿಗೆ ಮಾರ್ಗವನ್ನು ಘೋಷಿಸುವುದು ಉತ್ತಮ, ಆದ್ದರಿಂದ ನೀವು ಯಾವ ಸೇವೆಯನ್ನು ಬಳಸಿದರೂ ಪರವಾಗಿಲ್ಲ (ಇದಕ್ಕಾಗಿ ಉದಾಹರಣೆಗೆ, CircleCI), ಹೊಸ ಸೇವೆಯಲ್ಲಿ ಹೊಸ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನ ರಚನೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಡೇಟಾಸೆಟ್‌ಗಳಿಗೆ ಮಾರ್ಗವನ್ನು ಕಂಡುಹಿಡಿಯಲು ಪ್ರೋಗ್ರಾಂಗೆ ಸಾಧ್ಯವಾಯಿತು.

ತತ್ವ 5. ಬಿಲ್ಡ್, ಬಿಡುಗಡೆ, ರನ್ಟೈಮ್

ಡೇಟಾ ಸೈನ್ಸ್‌ನಲ್ಲಿರುವ ಅನೇಕ ಜನರು ತಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್ ಬರವಣಿಗೆ ಕೌಶಲ್ಯಗಳನ್ನು ಸುಧಾರಿಸಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ. ನಮ್ಮ ಪ್ರೋಗ್ರಾಂ ಸಾಧ್ಯವಾದಷ್ಟು ವಿರಳವಾಗಿ ಕ್ರ್ಯಾಶ್ ಆಗಲು ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಕಾಲ ವೈಫಲ್ಯಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಲು ನಾವು ಬಯಸಿದರೆ, ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಾವು 3 ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಬೇಕಾಗಿದೆ:

1. ಹಂತ ಅಸೆಂಬ್ಲಿಗಳು. ನಿಮ್ಮ ಬೇರ್ ಕೋಡ್ ಅನ್ನು ವೈಯಕ್ತಿಕ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ನೀವು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಕೋಡ್ ಮತ್ತು ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರುವ ಪ್ಯಾಕೇಜ್ ಎಂದು ಕರೆಯುತ್ತಾರೆ. ಈ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಅಸೆಂಬ್ಲಿ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
2. ಹಂತ ಬಿಡುಗಡೆ - ಇಲ್ಲಿ ನಾವು ನಮ್ಮ ಸಂರಚನೆಯನ್ನು ಅಸೆಂಬ್ಲಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತೇವೆ, ಅದು ಇಲ್ಲದೆ ನಮ್ಮ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ನಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಈಗ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧವಾಗಿದೆ.
3. ಮುಂದೆ ಹಂತ ಬರುತ್ತದೆ ಈಡೇರಿದ. ಇಲ್ಲಿ ನಾವು ನಮ್ಮ ಬಿಡುಗಡೆಯಿಂದ ಅಗತ್ಯ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸುವ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇವೆ.

ಮಾದರಿ ಅಥವಾ ಸಂಪೂರ್ಣ ಪೈಪ್‌ಲೈನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಇಂತಹ ವ್ಯವಸ್ಥೆಯು ನಿರ್ವಾಹಕರು ಮತ್ತು ಅಭಿವರ್ಧಕರ ನಡುವಿನ ಪಾತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆವೃತ್ತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರೋಗ್ರಾಂನ ಅನಗತ್ಯ ನಿಲುಗಡೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ.

ಬಿಡುಗಡೆ ಕಾರ್ಯಕ್ಕಾಗಿ, ಹಲವಾರು ವಿಭಿನ್ನ ಸೇವೆಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಇದರಲ್ಲಿ ನೀವು .yml ಫೈಲ್‌ನಲ್ಲಿ ನೀವೇ ಚಲಾಯಿಸಲು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬರೆಯಬಹುದು (ಉದಾಹರಣೆಗೆ, CircleCI ನಲ್ಲಿ ಇದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬೆಂಬಲಿಸಲು config.yml ಆಗಿದೆ). ಯೋಜನೆಗಳಿಗೆ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ವೀಲಿ ಅದ್ಭುತವಾಗಿದೆ.

ನಿಮ್ಮ ಯಂತ್ರ ಕಲಿಕೆಯ ಮಾದರಿಯ ವಿವಿಧ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ನೀವು ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು, ತದನಂತರ ಅವುಗಳನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡಿ ಮತ್ತು ಅಲ್ಲಿಂದ ನೀವು ಬರೆದ ಕಾರ್ಯಗಳನ್ನು ಬಳಸಲು ಅಗತ್ಯವಾದ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು ಅವುಗಳ ಆವೃತ್ತಿಗಳನ್ನು ಉಲ್ಲೇಖಿಸಿ. ಇದು ನಿಮ್ಮ ಮಾದರಿಗಾಗಿ API ಅನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಪ್ಯಾಕೇಜ್ ಅನ್ನು Gemfury ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ.

ತತ್ವ 6. ನಿಮ್ಮ ಮಾದರಿಯನ್ನು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಪ್ರಕ್ರಿಯೆಗಳಾಗಿ ರನ್ ಮಾಡಿ

ಇದಲ್ಲದೆ, ಪ್ರಕ್ರಿಯೆಗಳು ಹಂಚಿಕೊಂಡ ಡೇಟಾವನ್ನು ಹೊಂದಿರಬಾರದು. ಅಂದರೆ, ಪ್ರಕ್ರಿಯೆಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರಬೇಕು ಮತ್ತು ಎಲ್ಲಾ ರೀತಿಯ ಡೇಟಾವು ಪ್ರತ್ಯೇಕವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರಬೇಕು, ಉದಾಹರಣೆಗೆ, MySQL ಅಥವಾ ಇತರವುಗಳಂತಹ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳಲ್ಲಿ, ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಅವಲಂಬಿಸಿ.

ಅಂದರೆ, ಪ್ರಕ್ರಿಯೆಯ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಖಂಡಿತವಾಗಿಯೂ ಯೋಗ್ಯವಾಗಿಲ್ಲ, ಇಲ್ಲದಿದ್ದರೆ ಇದು ಮುಂದಿನ ಬಿಡುಗಡೆ / ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಬದಲಾವಣೆ ಅಥವಾ ಪ್ರೋಗ್ರಾಂ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಿಸ್ಟಮ್‌ನ ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಈ ಡೇಟಾವನ್ನು ತೆರವುಗೊಳಿಸಲು ಕಾರಣವಾಗಬಹುದು.

ಆದರೆ ಒಂದು ಅಪವಾದವಿದೆ: ಯಂತ್ರ ಕಲಿಕೆ ಯೋಜನೆಗಳಿಗಾಗಿ, ನೀವು ಲೈಬ್ರರಿಗಳ ಸಂಗ್ರಹವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು ಆದ್ದರಿಂದ ನೀವು ಪ್ರತಿ ಬಾರಿ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಅವುಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸದಂತೆ, ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಗ್ರಂಥಾಲಯಗಳು ಅಥವಾ ಅವುಗಳ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡದಿದ್ದರೆ. ಈ ರೀತಿಯಾಗಿ, ನಿಮ್ಮ ಮಾದರಿಯನ್ನು ಉದ್ಯಮದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವನ್ನು ನೀವು ಕಡಿಮೆಗೊಳಿಸುತ್ತೀರಿ.

ಮಾದರಿಯನ್ನು ಹಲವಾರು ಪ್ರಕ್ರಿಯೆಗಳಂತೆ ಚಲಾಯಿಸಲು, ನೀವು .yml ಫೈಲ್ ಅನ್ನು ರಚಿಸಬಹುದು ಅದರಲ್ಲಿ ನೀವು ಅಗತ್ಯ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಅವುಗಳ ಅನುಕ್ರಮವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು.

ತತ್ವ 7: ಮರುಬಳಕೆ

ನಿಮ್ಮ ಮಾದರಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ನಡೆಯುವ ಪ್ರಕ್ರಿಯೆಗಳು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ನಿಲ್ಲಿಸಲು ಸುಲಭವಾಗಿರಬೇಕು. ಹೀಗಾಗಿ, ಕೋಡ್ ಬದಲಾವಣೆಗಳು, ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳು, ತ್ವರಿತವಾಗಿ ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ಪ್ರಮಾಣದಲ್ಲಿ ತ್ವರಿತವಾಗಿ ನಿಯೋಜಿಸಲು ಮತ್ತು ಕೆಲಸದ ಆವೃತ್ತಿಯ ಸಂಭವನೀಯ ಸ್ಥಗಿತಗಳನ್ನು ತಡೆಯಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ಅಂದರೆ, ಮಾದರಿಯೊಂದಿಗೆ ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯು ಹೀಗಿರಬೇಕು:

• ಪ್ರಾರಂಭದ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಿ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಪ್ರಾರಂಭದ ಸಮಯ (ಆರಂಭಿಕ ಆಜ್ಞೆಯನ್ನು ನೀಡಿದ ಕ್ಷಣದಿಂದ ಪ್ರಕ್ರಿಯೆಯು ಕಾರ್ಯಾಚರಣೆಗೆ ಬರುವವರೆಗೆ) ಕೆಲವು ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚಿರಬಾರದು. ಮೇಲೆ ವಿವರಿಸಿದ ಲೈಬ್ರರಿ ಕ್ಯಾಶಿಂಗ್, ಪ್ರಾರಂಭದ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಒಂದು ತಂತ್ರವಾಗಿದೆ.
• ಸರಿಯಾಗಿ ಮುಗಿಸಿ. ಅಂದರೆ, ಸೇವಾ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಆಲಿಸುವುದನ್ನು ವಾಸ್ತವವಾಗಿ ಅಮಾನತುಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಈ ಪೋರ್ಟ್‌ಗೆ ಸಲ್ಲಿಸಿದ ಹೊಸ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ. ಇಲ್ಲಿ ನೀವು DevOps ಇಂಜಿನಿಯರ್‌ಗಳೊಂದಿಗೆ ಉತ್ತಮ ಸಂವಹನವನ್ನು ಹೊಂದಿಸಬೇಕು ಅಥವಾ ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು (ಆದ್ಯತೆ, ಸಹಜವಾಗಿ, ಎರಡನೆಯದು, ಆದರೆ ಸಂವಹನವನ್ನು ಯಾವಾಗಲೂ ಯಾವುದೇ ಯೋಜನೆಯಲ್ಲಿ ನಿರ್ವಹಿಸಬೇಕು!)

ತತ್ವ 8: ನಿರಂತರ ನಿಯೋಜನೆ/ಏಕೀಕರಣ

ಅನೇಕ ಕಂಪನಿಗಳು ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ನಿಯೋಜನೆ ತಂಡಗಳ ನಡುವೆ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಬಳಸುತ್ತವೆ (ಅಂತರಿಕ ಬಳಕೆದಾರರಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುವುದು). ಇದು ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಅದನ್ನು ಸುಧಾರಿಸುವಲ್ಲಿ ಪ್ರಗತಿಯನ್ನು ಬಹಳವಾಗಿ ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. ಇದು DevOps ಸಂಸ್ಕೃತಿಯನ್ನು ಹಾಳು ಮಾಡುತ್ತದೆ, ಅಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಏಕೀಕರಣವು ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿದೆ.

ಆದ್ದರಿಂದ, ನಿಮ್ಮ ಅಭಿವೃದ್ಧಿ ಪರಿಸರವು ನಿಮ್ಮ ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರವಾಗಿರಬೇಕು ಎಂದು ಈ ತತ್ವವು ಹೇಳುತ್ತದೆ.

ಇದು ಅನುಮತಿಸುತ್ತದೆ:

1. ಬಿಡುಗಡೆಯ ಸಮಯವನ್ನು ಹತ್ತಾರು ಬಾರಿ ಕಡಿಮೆ ಮಾಡಿ
2. ಕೋಡ್ ಅಸಾಮರಸ್ಯದಿಂದಾಗಿ ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ.
3. ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಜನರು ಈಗ ಒಂದೇ ತಂಡವಾಗಿರುವುದರಿಂದ ಇದು ಸಿಬ್ಬಂದಿಯ ಮೇಲಿನ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಇದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಪರಿಕರಗಳೆಂದರೆ CircleCI, Travis CI, GitLab CI ಮತ್ತು ಇತರರು.

ನೀವು ತ್ವರಿತವಾಗಿ ಮಾದರಿಗೆ ಸೇರ್ಪಡೆಗಳನ್ನು ಮಾಡಬಹುದು, ಅದನ್ನು ನವೀಕರಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ತಕ್ಷಣವೇ ಪ್ರಾರಂಭಿಸಬಹುದು, ಆದರೆ ವಿಫಲವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಆವೃತ್ತಿಗೆ ತ್ವರಿತವಾಗಿ ಹಿಂತಿರುಗಲು ಸುಲಭವಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಅಂತಿಮ ಬಳಕೆದಾರರು ಅದನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ನೀವು ಉತ್ತಮ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಇದನ್ನು ವಿಶೇಷವಾಗಿ ಸುಲಭವಾಗಿ ಮತ್ತು ತ್ವರಿತವಾಗಿ ಮಾಡಬಹುದು.

ವ್ಯತ್ಯಾಸಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಿ !!!

ತತ್ವ 9. ನಿಮ್ಮ ದಾಖಲೆಗಳು

ಲಾಗ್‌ಗಳು (ಅಥವಾ "ಲಾಗ್‌ಗಳು") ಈವೆಂಟ್‌ಗಳಾಗಿವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪಠ್ಯ ಸ್ವರೂಪದಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡಲಾಗುತ್ತದೆ, ಅದು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ (ಈವೆಂಟ್ ಸ್ಟ್ರೀಮ್) ಸಂಭವಿಸುತ್ತದೆ. ಒಂದು ಸರಳ ಉದಾಹರಣೆ: "2020-02-02 - ಸಿಸ್ಟಮ್ ಮಟ್ಟ - ಪ್ರಕ್ರಿಯೆಯ ಹೆಸರು." ಪ್ರೋಗ್ರಾಂ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಡೆವಲಪರ್ ಅಕ್ಷರಶಃ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡುವಂತೆ ಅವುಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಅವರು ಪ್ರಕ್ರಿಯೆಗಳ ಪ್ರಗತಿಯನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಡೆವಲಪರ್ ಸ್ವತಃ ಉದ್ದೇಶಿಸಿದಂತೆ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.

ನಿಮ್ಮ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಲಾಗ್‌ಗಳನ್ನು ನೀವು ಸಂಗ್ರಹಿಸಬಾರದು ಎಂದು ಈ ತತ್ವವು ಹೇಳುತ್ತದೆ - ನೀವು ಅವುಗಳನ್ನು ಪರದೆಯ ಮೇಲೆ "ಔಟ್‌ಪುಟ್" ಮಾಡಬೇಕು, ಉದಾಹರಣೆಗೆ, ಸಿಸ್ಟಮ್‌ನ ಪ್ರಮಾಣಿತ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಇದನ್ನು ಮಾಡಿ. ಮತ್ತು ಈ ರೀತಿಯಾಗಿ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಟರ್ಮಿನಲ್‌ನಲ್ಲಿನ ಹರಿವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಲಾಗ್‌ಗಳನ್ನು ಉಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವೇ? ಖಂಡಿತ ಇಲ್ಲ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಇದನ್ನು ಮಾಡಬಾರದು-ಅದನ್ನು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳಿಗೆ ಬಿಡಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನೈಜ-ಸಮಯದ ವೀಕ್ಷಣೆಗಾಗಿ ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಅಥವಾ ಟರ್ಮಿನಲ್‌ಗೆ ಲಾಗ್‌ಗಳನ್ನು ಮಾತ್ರ ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು ಅಥವಾ ಅದನ್ನು ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಡೇಟಾ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು (ಉದಾಹರಣೆಗೆ ಹಡೂಪ್). ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಾರದು ಅಥವಾ ಸಂವಹಿಸಬಾರದು.

ತತ್ವ 10. ಪರೀಕ್ಷೆ!

ಕೈಗಾರಿಕಾ ಯಂತ್ರ ಕಲಿಕೆಗಾಗಿ, ಈ ಹಂತವು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಮಾದರಿಯು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.

ಪರೀಕ್ಷೆಗಳನ್ನು ಪೈಟೆಸ್ಟ್ ಬಳಸಿ ರಚಿಸಬಹುದು ಮತ್ತು ನೀವು ರಿಗ್ರೆಷನ್/ವರ್ಗೀಕರಣ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ ಸಣ್ಣ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪರೀಕ್ಷಿಸಬಹುದು.

ಆಳವಾದ ಕಲಿಕೆಯ ಮಾದರಿಗಳಿಗೆ ಒಂದೇ ಬೀಜವನ್ನು ಹೊಂದಿಸಲು ಮರೆಯಬೇಡಿ ಇದರಿಂದ ಅವು ನಿರಂತರವಾಗಿ ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ.

ಇದು 10 ತತ್ವಗಳ ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆಯಾಗಿದೆ, ಮತ್ತು, ಅವುಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಪ್ರಯತ್ನಿಸದೆ ಮತ್ತು ನೋಡದೆ ಅವುಗಳನ್ನು ಬಳಸುವುದು ಕಷ್ಟ, ಆದ್ದರಿಂದ ಈ ಲೇಖನವು ಆಸಕ್ತಿದಾಯಕ ಲೇಖನಗಳ ಸರಣಿಗೆ ಕೇವಲ ಮುನ್ನುಡಿಯಾಗಿದೆ, ಇದರಲ್ಲಿ ನಾನು ಹೇಗೆ ರಚಿಸುವುದು ಎಂಬುದನ್ನು ನಾನು ಬಹಿರಂಗಪಡಿಸುತ್ತೇನೆ. ಕೈಗಾರಿಕಾ ಯಂತ್ರ ಕಲಿಕೆಯ ಮಾದರಿಗಳು, ಅವುಗಳನ್ನು ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಹೇಗೆ ಸಂಯೋಜಿಸುವುದು ಮತ್ತು ಈ ತತ್ವಗಳು ನಮ್ಮೆಲ್ಲರಿಗೂ ಜೀವನವನ್ನು ಹೇಗೆ ಸುಲಭಗೊಳಿಸಬಹುದು.

ಯಾರಾದರೂ ಬಯಸಿದಲ್ಲಿ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬಿಡಬಹುದಾದ ತಂಪಾದ ತತ್ವಗಳನ್ನು ಬಳಸಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.

ಮೂಲ: www.habr.com