یوشا

Introduction
Types of packages
Characteristics of a package
The Laravel package!
Components of a Laravel package
Example of a Laravel package
Creating your Laravel package
- 1- Package structure
- 2- Required equipments
- 3- Create package structure
- 4- Update package manifest
- 5- Create route
- 6- Create configuration file
- 7- Create command for package
- 8- Create controller
- 9- Create middleware
- 10- Create [database] migration
- 11- Create view
- 12- Create [view] assets
- 13- Create service provider
- 14- Create a manual/help file
- 15- Build our package
- 16- Test/Use our package
Best practices
Publish your Laravel package
Conclusion

Introduction

In context of software development - particularly with PHP - a package is a modular, reusable piece of functionality that can be integrated into an application. Packages are designed to extend or enhance capabilities of a application by adding specific features or tools without reinventing wheel!

Now why use packages instead of developing built-in code and features?

Because:

Save time & effort: Instead of coding complex functionality (like payments, authn, or APIs), you use a well-tested package, by too many users (well-cooked)
Follow best practices: Good packages are built by experts(mostly), ensuring security, performance, and maintainability.
Easy updates: When a package improves, you get upgrades without rewriting your code. (composer update vendorname/packagename)
Community-Powered: Many packages are open-source, meaning developers worldwide contribute to improve them.

So let's avoid reinventing wheel!

Types of packages

Each type of package solves problems at different levels - from tiny utilities, authn, dev tools to massive libraries - all shareable through dependency manager(like Composer) and designed to work harmoniously in your project ecosystem. These types are:

Standalone packages: AKA framework-agnostic packages, these are general-purpose packages that can be used with/without any PHP framework. Like guzzlehttp, monolog, redbean, etc...
Framework-Specific packages: These are tailored specifically for framework(Laravel, Symfony, YAF...) and leverage its features, such as service providers, facades, and configuration systems. Like spatie/laravel-permission, wordpress plugins, symfony/console, codeigniter4/cache, etc...

Characteristics of a package

A package is defined by following key characteristics:

Reusability: A package encapsulates functionality that can be reused across multiple applications.
Modularity: It is self-contained, meaning it includes all necessary components (like routes, controllers, views, configuration files) to perform its intended function.
Dependency management: Application's packages often rely on Composer, PHP's dependency manager, for installation and version control.

These traits ensure that packages maintain consistency, reduce redundancy, and simplify integration in software development.

The Laravel package!

A Laravel package is like a ready-made toolbox that adds extra features to our Laravel application. This can be a kind of Open-Close principle... Instead of building everything from scratch, you can install a package to quickly add things like:

Authentication (signin/signup/signout)
Payment processing (Stripe, PayPal)
File uploads
API tools
Admin dashboards
etc...

Packages save you time and let you focus on our application's unique parts. They’re easy to install (usually via Composer) and often come with clear instructions(I hope :D).
Think of them as "plugins" for Laravel!

Components of a Laravel package

A Laravel package is made up of several key components that work together to extend our application's functionality. It bundles some components to provide reusable functionality. Once structured correctly, users/developers can install it via Composer and integrate it seamlessly into their applications...

Here is components of a Laravel package:

Service Provider: "bridge" between our package and Laravel. Registers our package’s services, routes, views, and configurations.
Configuration file: A config file (usually config/mypackagename.php) where users/developers can customize package settings.
Routes: Defines web or API routes for our package.
Migrations: Database tables and required records/rows needed by our package. (if our package needs data storage)
Views: Frontend components (HTML mostly) stored in resources/views/.
Controllers: Handles logic and processes requests. Like a microcontroller in electronic world!
Models: Interacts with database. Mirror of a table in database. (if our package needs data storage)
Assets: Frontend assets (JavaScript, CSS, images) stored in resources/assets/.
Commands: Custom Artisan commands for package-specific tasks. Like php artisan mypackagename:install
Facades: Provides a simple interface to our package features. Like MyPackageName::doSomething()
Middleware: Adds request/response filtering for our package. Like authn checks.
Tests: PHPUnit or Pest tests to ensure reliability and QA.
Composer.json: Defines package dependencies, autoloading, and metadata... (something like manifest)

Note that some of components are optional and can be ignored in packages.

Example of a Laravel package

Now here's a great example of a popular Laravel package to quick-start: Laravel Horizon
It provides a beautiful UI for managing our Redis queues... What it does, gives us a cool dashboard and powerful tools to monitor and manage our Laravel queues. It's like having mission control for our background jobs.

Installation
composer require laravel/horizon

Configuration
php artisan horizon:install

Usage
Access the dashboard at http://domain/horizon (behind authn by default)

See? too easy!

This Laravel package is perfect for apps that handle email processing, report generation, or any heavy background tasks...

Creating your Laravel package

Laravel packages let you encapsulate reusable functionality - whether it's a handy utility, a full-featured module, or an integration with an external service. By creating your own package, you can share code across projects, maintain clean architecture by separating concerns, contribute to open-source and boost your dev cred!

To create your own Laravel package, you should simply: setup the package structure, define a service provider, publish assets, test the package, and finally distribute via Packagist. That's all

Let's start!

1- Package structure

The structure of our package will be something like this:

All components were explained in section "Components of a Laravel package" above.

my-package/
├── src/
│   ├── MyPackageServiceProvider.php
|   ├── Http/
│   │   ├── Middleware/
│   │   │   └── ExampleMiddleware.php
│   │   └── Controllers/
│   │       └── ExampleController.php
│   ├── Console/
│   │   └── Commands/
│   │       └── ExampleCommand.php
│   ├── migrations/
│   │   └── 2023_12_05_000000_create_examples_table.php
│   ├── resources/
│   │   ├── views/
│   │   │   └── example.blade.php
│   │   └── assets/
│   │       └── css/
│   │           └── example.css
│   ├── config/
│   │   └── my-package.php
│   └── routes/
│       └── web.php
├── composer.json
└── README.md

And yes, we are keeping config, database, routes, and resources directories INSIDE src directory. Because this style is a self-contained structure, simpler publishing, and fits small projects.

But keeping config, database, routes, and resources directories OUTSIDE src directory fits large or public packages, aligns with Laravel community standards, and ensures PSR-4 compliance.

Note: Both styles are valid, but decision depends on your package's purpose and audience... For most developers, especially those contributing to Laravel ecosystem, outside src structure is preferred because it adheres to widely accepted conventions and improves maintainability. However, for internal or smaller projects, inside src structure can offer simplicity and encapsulation.

2- Required equipments

1- Infrastructure: PC! (laptop or desktop)

2- Platform: Windows or GNU/Linux OS

3- Interpreter: PHP >= 7.4

4- Dependency manager: Composer

5- Editor/IDE: Apache Netbeans, Ms VSCode, Eclipse IDE, Notepad++, Vim, etc...

6- Web server: Apache HTTPD, NGINX, PHP's built-in server

3- Create package structure

Now create all directories and files(empty) like above... To do this, you can use composer init and answer questions to bootstrap our package.

Or open system terminal/CMD and use mkdir dirname, touch filename, echo > filenamecommands to create them manually.

Or download & run my shell scripts to generate them for you: Windows BATCH, GNU/Linux BASh

4- Update package manifest

Now we must update our composer.json file for package needs:

{
   "name": "example/my-package",
   "description": "A simple Laravel package for example.",
   "type": "library",
   "version": "1.0.0",
   "authors": [
      {
         "name": "Your Fullname",
         "email": "name@domain.tld"
      }
   ],
   "require": {
      "php": "7.4.*",
      "illuminate/support": "10.*",
      "illuminate/console": "10.*",
      "illuminate/database": "10.*",
      "illuminate/routing": "10.*"
   },
   "autoload": {
      "psr-4": {
         "Example\\MyPackage\\": "src/"
      }
   },
   "extra": {
      "laravel": {
         "providers": [
            "Example\\MyPackage\\MyPackageServiceProvider"
         ]
      }
   }
}

Some explanation:

"version" tag will be match with your Git's repository tag.
"psr-4" tag defines how PHP classes are designed and autoloaded. Look for classes by PSR-4 STYLE in that folder when I use this namespace.
"Example\\MyPackage\\" tag is our logical(inside codes) path which maps to our "src/" physical(filesystem) path.
"laravel": {"providers"... tags are for Laravel-specific packages (uses Laravel features). And it's auto-registers our ServiceProvider when someone installs our package via Composer.

Note: When creating a Laravel package, you do NOT need to require the entire laravel/framework in your manifest file composer.json. Instead, you should only require the specific components("illuminate" packages) that your package depends on. By this way your package remains lightweight and does not include unnecessary of dependencies on the projects that use it. (avoid dependency hell!)

5- Create route

File src/routes/web.php:

<?php

use Illuminate\Support\Facades\Route;
use Example\MyPackage\Http\Controllers\ExampleController;

Route::get('/example', [ExampleController::class, 'index'])
   ->middleware('example.middleware') // Apply our middleware directly. Type: Route Middleware
   ->name('example.index');           // Assign a name to the route.

Some explanation:

'/example' our package's feature URL.

'index' our ExampleController's method to call.

->name('example.index') a unique name for that route/URL. So we can call it anywhere instead of hardcoding it's URL. Can be used in:

// Blade template
<a href="{{ route('example.index') }}">Example</a>
// Controller
return redirect()->route('example.index');
// Middleware or services
$url = route('example.index');
// Testing (PHPUnit)
$response = $this->get(route('example.index'));

6- Create configuration file

File src/config/my-package.php:

<?php

return [
   'greeting' => 'Awesome hello from MyPackage!!',
];

A complex config!

7- Create command for package

This command can be used by user/developer in their Laravel application.

File src\Console\Commands\ExampleCommand.php:

<?php

namespace Example\MyPackage\Console\Commands;

use Illuminate\Console\Command;

class ExampleCommand extends Command
{
   protected $signature = 'my-package:example'; // The command that user uses and run.
   protected $description = 'An example command description for MyPackage.';

   public function handle()
   {
      // Example logic.
      $this->info('Hello from MyPackage command!');
   }
}

Example usage in Laravel application: php artisan my-package:example

8- Create controller

File src/Http/Controllers/ExampleController.php:

<?php

namespace Example\MyPackage\Http\Controllers;

use Illuminate\Routing\Controller;
use Illuminate\Support\Facades\Config;

class ExampleController extends Controller
{
   public function index()
   {
      $greeting = config('my-package.greeting');
      return view('my-package::example', compact('greeting'));
   }
}

The double colon (::) in view('my-package::example') is Laravel's syntax for package views, and it prevents naming collisions.

Because imagine our package has example.blade.php file, and the main app(consumer) also has example.blade.php file...! so that namespace ensures Laravel uses the correct file.

my-package = Our package's view namespace (registered via loadViewsFrom())
example = The view file name (without .blade.php)Because using the namespace (::) prevents naming collisions.

Note: For better organization, always put all HTTP protocol related classes (Controllers) under /Http/ directory.

9- Create middleware

A middleware is a gatekeeper for HTTP requests in our package. It checks, modifies, or blocks requests before they reach our routes/controllers.

There are 3 types of middlewares:

Global = Runs on every HTTP request, like CORS headers, applies in Kernel.php file.
Route = Runs on specific routes, like Authentication & role checks, applies in routes files.
Group = Runs on routes in a named group, like API auth & web session handling, applies in routes files.

File src/Http/Middleware/ExampleMiddleware.php:

<?php

namespace Example\MyPackage\Http\Middleware;

use Closure;
use Illuminate\Support\Facades\Response;

class ExampleMiddleware
{
   public function handle($request, Closure $next)
   {
      // Example logic.
      if ($request->has('allow')) {
         return $next($request);
      }

      return response('Access Denied! XD', 403);
   }
}

Then register the middleware in the our package's service provider, inside boot() method.

File src/MyPackageServiceProvider.php:

class MyPackageServiceProvider extends ServiceProvider
{
   public function boot()
   {
      // Register our package's middleware.
      $this->app['router']->aliasMiddleware('example.middleware', ExampleMiddleware::class);

In Laravel, middlewares are typically registered in boot() method of a service provider rather than register() method... because:

register() method is primarily used for binding services into container. Since middlewares DO NOT need to be bound into the service container, this method isn't suitable for middleware registration.
boot() method is where middleware should be registered, because it gets executed AFTER all services have been registered. So middlewares consumes those services!

Another thing, it doesn't technically matter if you put middleware at top or bottom of boot() method, but there's best practices to put middleware at the TOP of boot() if:

It's essential for other package features (routes, controllers, etc.)
It's a global middleware (runs on every request)

Note: For better organization, always put all HTTP protocol related classes (Middleware) under /Http/ directory.

10- Create [database] migration

File src/migrations/2023_12_05_000000_create_examples_table.php:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateExamplesTable extends Migration
{
   public function up()
   {
      Schema::create('examples', function (Blueprint $table) {
         $table->id();
         $table->string('name');
         $table->timestamps();
      });
   }

   public function down()
   {
      Schema::dropIfExists('examples');
   }
}

Note that Laravel will automatically include our package's migrations...

Blueprint, really nice class name.

11- Create view

File src/resources/views/example.blade.php:

<!DOCTYPE html>

<html>
<head>
    <title>MyPackage</title>
    <link rel="stylesheet" href="{{ asset('vendor/my-package/css/example.css') }}">
</head>

<body>
    <h1>{{ $greeting }}</h1>
</body>
</html>

This asset/CSS will resolve to http://<domain>/vendor/my-package/css/example.css URL.

12- Create [view] assets

File src/resources/assets/css/example.css:

body {
   font-family: Arial, sans-serif;
   background-color: #f4f4f4;
   text-align: center;
   padding: 50px;
}

h1 {
   color: #268f22;
}

13- Create service provider (the bridge)

The service provider is the entry point of package. It registers routes, middleware, commands, and other components...

File src/MyPackageServiceProvider.php:

<?php

namespace Example\MyPackage;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\URL;
use Example\MyPackage\Console\Commands\ExampleCommand;
use Example\MyPackage\Http\Middleware\ExampleMiddleware;

class MyPackageServiceProvider extends ServiceProvider
{
   public function boot()
   {
      // Register our middleware.
      $this->app['router']->aliasMiddleware('example.middleware', ExampleMiddleware::class);

      // Publish configuration file.
      $this->publishes([
         __DIR__ . '/config/my-package.php' => config_path('my-package.php'),
      ], 'config');

      // Register migrations.
      $this->loadMigrationsFrom(__DIR__ . '/migrations');

      // Register routes.
      $this->loadRoutesFrom(__DIR__ . '/routes/web.php');

      // Register views.
      $this->loadViewsFrom(__DIR__ . '/resources/views', 'my-package');

      // Publish assets.
      $this->publishes([
         __DIR__ . '/resources/assets/' => public_path('vendor/my-package'),
      ], 'assets');

      // Publish assets.
      $this->publishes([
         __DIR__ . '/migrations' => database_path('migrations'),
      ], 'migrations');  // <- The tag is defined here will be used in `php artisan vendor:publish --tag=HERE` command.

      // Register commands.
      if ($this->app->runningInConsole()) {
         $this->commands([
            ExampleCommand::class,
         ]);
      }
   }

   public function register()
   {
      // Merge configuration.
      $this->mergeConfigFrom(
         __DIR__ . '/config/my-package.php',
         'my-package'
      );
   }
}

Some explanation:

$this->loadRoutesFrom / $this->loadViewsFrom / $this->loadMigrationsFrom: These lines tells to Laravel that my package has some route/view/migration definitions in those files... So load them into your application.
$this->publishes: This lines copies files/folders from our package's resources/migration/route directory to the Laravel app's folders. That's all!
public_path('vendor/my-package'): This will copy files from resources/assets (inside our new package) to public/vendor/my-package of consumer/app.

14- Create a manual/help file

It is best to create a README.md file to help users of your package with following sections: about, installation, publishing, configurations, migrations, commands, usage, license etc...

15- Build our package

To make our package ready, go to package's root directory and run the following commands:

composer install

^ Installs package dependencies.

composer dump-autoload

^ Update autoloader after adding new classes.

16- Test/Use our package (locally)

For this, we create a new Laravel application to use/consume our Laravel package.

So let's create a new Laravel application:

composer create-project "laravel/laravel:10.*" my-laravel-app

Now open application's manifest file composer.json, and add the following lines:

"repositories": [
    {
        "type": "path",
        "url": "../myfolder/my-package"
    }
]

In this file, we tell Composer about an additional package repository (other than Packagist.org) that is stored locally on the system. Composer will use this repository to find and install packages... so URL must be correct & address our package to the application.

Then normally install our package inside this new Laravel app:

composer require example/my-package

And update autoloader after adding new classes: (app)

composer dump-autoload

So our package is added into the application, but NOT published(copy its stuff) yet.

To verify our package's service provider is loaded in Laravel application: (app)

php artisan package:discover

It must give you something like this: (app)

example/my-package ............................... DONE
laravel/sail ............................................... DONE
laravel/sanctum ........................................ DONE
laravel/tinker ............................................ DONE
nesbot/carbon ........................................... DONE
nunomaduro/collision ................................ DONE
nunomaduro/termwind ............................... DONE
spatie/laravel-ignition ................................. DONE

Now run the following commands to publish/copy our package config/assets/migrations inside the application: (app)

php artisan vendor:publish --tag=config

php artisan vendor:publish --tag=assets

php artisan vendor:publish --tag=migrations

Finally, run application's migrations(if any) then clear ALL caches: (app)

php artisan migrate

php artisan optimize:clear

Best practices

Here are a few short best practices when creating a package:

Testing: Always write unit tests, using PHPUnit or Pest libraries.
Documentation: Include a detailed README.md file in your package's root directory. (Add Overview, Installation, Configuration, Usage, Testing, Contributing...)
Versioning: Use SemVer or any other versioning standard (Major.Minor.Micro.Build).
PSR standards compliance: Follow PSR-12 coding standards.
Security: Validate inputs in middleware/controllers and use CSRF protection.

Publish your Laravel package

Once your Laravel package is complete, tested, and ready for public use, you can submit it to Packagist.org , the official PHP package repository for Composer tool. This allows developers around the world to install your package via a simple command:

composer require example/my-package

Conclusion

Packages streamline Laravel development by promoting reuse and modularity. Follow this guide to create, test, and share your own! Contribute to open-source and avoid "dependency hell" by requiring only essential illuminate/* components.

Project repository

Download Zip or TArGz

Helpful information

Essential commands after package creation:

In your package

Command	Purpose
composer install	Install package dependencies
composer dump-autoload	Update autoloader after adding new classes

In your application (consumer)

Command	Purpose
composer require vendor/package-name	Install the package
composer dump-autoload	Refresh autoloader to detect new classes
php artisan package:discover	Auto-register package service providers
php artisan vendor:publish --tag=package-config	Publish config files (if any)
php artisan vendor:publish --tag=package-migrations	Publish migration files (if any)
php artisan vendor:publish --tag=assets	Publish asset files (if any)
php artisan migrate	Run packages migrations
php artisan optimize:clear	Clear all caches (routes, views, config)

۰ نظر

یوشا آل ایوب

۰۸

۱۴۰۱/۰۹

نقشه راه متخصص جرمیابی دیجیتال / Digital forensic specialist roadmap

تعریف جرمیابی دیجیتال: به مجموعه فرایند جمع آوری، ارزیابی و ارائه مدارک جمع آوری شده از تجهیزات دیجیتال گفته میشود.

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

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

(به انگلیسی Digital Forensics and Incident Response (DFIR))

برای بزرگنمایی کلیک کنید

۰ نظر

یوشا آل ایوب

۰۱

۱۴۰۱/۰۶

کانفیگ هسته Linux برای محیط debugging و production

- کانفیگ hardening شده هسته Linux برای محیط production x64:

(قبل از کامپایل هسته Linux بهمین شکل پارامترهارو داخل فایل .config موجود در سورس لینوکس تون اعمال کنید)

ادامه مطلب...

۱ نظر

یوشا آل ایوب

۱۸

۱۴۰۱/۰۳

اصول استفاده از Exception

1- Exception ها، استثنا هستن! فقط باید از اونها برای مواجه با مشکلات غیر قابل پیش بینی استفاده کنید.

2- هرگز از Exception برای کنترل جریان/flow نرم افزار استفاده نکنید. اینکار باعث میشه که نتونید مسیر اجرای کد رو دنبال کنید و پرفورمنس نرم افزار هم کاهش پیدا میکنه. (مثل دستور GoTo که در برخی زبانها وجود داره)

3- هرگز شی Exception رو بعنوان مقدار و خروجی return نکنید.

4- Exception فقط باید حاوی اطلاعات رخداد/رویداد باشد و نباید حاوی پارامترها(یا اطلاعات اضافی) باشه که روی نحوه انجام و منطق داخل بلوک catch تاثیر بذاره.

5- هرگز Exception های زیرساختی/داخلی مثل SystemException, OutOfMemoryException, StackOverflowException, ComException, ExecutionEngineException, NullReferenceException, IndexOutOfRangeException رو پرتاب نکنید.

6- برای حالت debug نرم افزار Exception پرتاب نکنید.

7- داخل متد toString() کلاس هاتون Exception پرتاب نکنید. اینکار عمل debugging رو سخت می کنه. (از این متد برای debug کردن استفاده میشه)

8- داخل توابع مقایسه ای(true/false) و equal هرگز Exception پرتاب نکنید.

9- هرگز StackOverflowException و OutOfMemoryException رو catch نکنید. اینها غیرقابل کنترل و هندل شدن هستن.

10- همیشه Exception های سطح پایین و general رو به Exception های ریز تر و خاص تر wrap کنید. مثل:

NotFoundException -> FileNotFoundException/URLNotFoundException

11- همیشه عملیات پاکسازی/Cleanup رو در بلوک finally قراربدید و نه در بلوک catch. بلوک finally همیشه اجرا میشه اما بلوک catch فقط هنگام رخداد Exception اجرا میشه.

12- فقط باید زمانی Exception رو catch کنید که میتونید بخوبی مشکل رو handle و recovery کنید. درغیراینصورت بهتره Exception رو catch نکنید. (چون درواقع صرفا مخفیش کردید)

13- بهتره که هنگام timeout شدن یک عملیات، TimeoutException پرتاب کنید نه اینکه توسط if/else اونرو handle کنید.

14- در بلوک finally هرگز Exception پرتاب نکنید.

15- صرفا Log و rethrow کردن یک Exception در بلوک catch بمعنای handle کردنش نیست.

16- هرگز Exception مادر/عمومی مثل Exception رو throw نکنید.

17- برای wrap کردن Exception همیشه از کلاس مادر Exception یا RuntimeException ارث بری کنید.

18- بهتره در بلوک catch از if/else استفاده نکنید تا از ایجاد branch های تودرتو جلوگیری بشه.

19- همیشه پیامهای Exception رو در فایلی log کنید.

20- بجای throw ex از throw استفاده کنید تا پیامهای stacktrace قبلی و کنونی موجود در ex حفظ بشن.

catch(Exception ex)
{
   throw;
}

۰ نظر

یوشا آل ایوب

۱۶

۱۴۰۰/۱۱

گنولینوکس Slackware 15 امد

بلخره بعد از مدت ها گنولینوکس Slackware نسخه 15 stable ترخیص شد!

تغییرات مهم

- Kernel 5.15.19 LTS

- Python 3.9 ,BASh 5.1, LLVM 13, GCC 11.2, PHP 7.4

- XFCE 4.16, KDE 5.23, X Server 1.20

- GRUB 2.0.6, OpenSSL 1.1.1m, BinUtils 2.37, GNU C lib 2.33

- تغییر درایورها

- پشتیبانی بهتر از اینترفیس NVMe و بسترهای نوع UEFI

- جایگزین شدن Elogind بجای ConsoleKit2

- اضافه شدن FFmpeg و Lame

- جایگزین شدن postfix بجای sendmail

- جایگزین شدن Dovecot بجای pop3d و imapd

- جایگزین شدن iproute2 بجای net-tools

- اضافه شدن Qt 5.15 و GTK4

- اضافه شدن تعدادی User/Group جدید

- حذف و اضافه شدن تعداد زیادی package

و بسیاری بهینه سازی و بروز رسانی های دیگه...

وبسایت

http://www.slackware.com

دانلود

32bit

https://mirrors.slackware.com/slackware/slackware-iso/slackware-15.0-iso

https://ftp.osuosl.org/pub/slackware-iso/slackware-15.0-iso

64bit

https://mirrors.slackware.com/slackware/slackware-iso/slackware64-15.0-iso

https://ftp.osuosl.org/pub/slackware-iso/slackware64-15.0-iso

64bit live

https://slackware.nl/slackware/slackware-live/slackware64-15.0-live

مستندات

https://docs.slackware.com

یوشا آل ایوب

۰۵

۱۴۰۰/۱۰

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

(به انگلیسی Digital Forensics and Incident Response (DFIR))

نام توزیع	کشور سازنده	نوع پروانه	معماری	تاریخ بروزرسانی	وبسایت
Kali (BackTrack)	سوئیس	رایگان/تجاری Opensource/Binary	i686, x64	2021	kali.org
BlackArch	آمریکا	رایگان Opensource/Binary	x64	2021	blackarch.org
Grml	استرالیا	رایگان Opensource	i686, x64	2021	grml.org
Parrot OS	ایتالیا	رایگان Opensource/Binary	x64	2021	parrotlinux.org
Pentoo	سوئیس	رایگان Opensource	i686, x64	2020	pentoo.ch
CAINE	ایتالیا	رایگان Opensource	x64	2021	caine-live.net
نام توزیع	کشور سازنده	نوع پروانه	معماری	تاریخ بروزرسانی	وبسایت
ForLEx	ایتالیا	رایگان Opensource	x86	2019-10	forlex.it
PALADIN	آمریکا	تجاری Opensource/Binary	x86, x64	?	sumuri.com
DEFT Linux	ایتالیا	رایگان	i686	2018-09	deftlinux.net
BackBox Linux	ایتالیا	رایگان Opensource/Binary	x86, x64	2020	backbox.org
ALT Linux	روسیه	رایگان Opensource/Binary	i586, x64	2021	en.altlinux.org basealt.ru
radare2	?	رایگان Opensource	x86	2021	rada.re/n/
ArchStrike	آمریکا	رایگان Opensource	i686, x64	2021	archstrike.org
Santoku	?	رایگان Opensource	x64	2014	santoku-linux.com
نام توزیع	کشور سازنده	نوع پروانه	معماری	تاریخ بروزرسانی	وبسایت
Bugtraq	اسپانیا	رایگان	x86, x64	2013	bugtraq-team.net
URIX OS	بلغارستان	رایگان	x64	2016-01	urix.us
SIFT	؟	؟	x64	2019	digital-forensics.sans.org
Cyborg Linux	هند	رایگان Opensource	x86	2015	cyborg.ztrela.com
Security Onion	آمریکا	رایگان Opensource/Binary	x86	2021	securityonion.net
ADIA	?	رایگان Opensource	x64	2017	forensics.cert.org
NST	آمریکا	رایگان Opensource	x64	2021	networksecuritytoolkit.org
Tsurugi Linux	Japan	رایگان Opensource	x64	2021	https://tsurugi-linux.org

دانلود فایل PDF

۱ نظر

یوشا آل ایوب

۱۶

۱۴۰۰/۰۷

نکات و اصول مهم در خرید و نگهداری از گیاه

1. هنگام خرید گیاه: زیاد به توصیه های فروشنده اعتماد نکنید!

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

2. تعویض گلدان: عجله نکنید

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

اما نشانه های نیاز فوری به تعویض گلدان:

ریشه ها از زیر گلدان بیرون زده اند.
رشد گیاه، بدون مشکل ظاهری متوقف شده است.
خاک به سرعت خشک میشود (یعنی ریشه ها فضای گلدان را پر کرده اند).

3. انتخاب گیاهان مناسب برای افراد تازه کار

گیاهان مقاوم، کم توقع و دهه شصتی! بهترین انتخاب برای شروع هستند:

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

نکته: گیاهان با برگهای سبز تیره معمولاً در نور کم هم رشد میکنند، زیرا کلروفیل بیشتری دارند و نور را بهتر جذب میکنند.

نکته 2: گیاهان ابلک/ابلغ (دارای رگه های سفید، طلایی یا صورتی) معمولاً به نور بیشتری نیاز دارند. اگر نور کافی نباشد، رنگ برگها محو و سبز میشوند.

4. آبیاری صحیح: عامل اصلی مرگ گیاهان خانگی

اشتباه رایج: آبیاری بیش از حد که باعث پوسیدگی ریشه میشود.
راه تشخیص نیاز به آبیاری:
- انگشت خود را ۲-۳ سانتیمتر در خاک فرو ببرید. اگر خشک بود، آبیاری کنید.
- برای گیاهان گوشتی مانند کاکتوس ها و ساکولنت ها، اجازه دهید خاک کاملاً خشک شود.
نکته: گلدانهای دارای زهکشی مناسب(سوراخ زیر گلدان + سنگ ریز کف گلدان) انتخاب کنید تا آب اضافه خارج شود و ته نشین نشود.

5. تأثیر رطوبت و دمای محیط

بیشتر گیاهان آپارتمانی به رطوبت ۴۰ تا ۶۰ درصد نیاز دارند. در هوای خشک، برگها قهوه ای یا خشک میشوند.
میانگین رطوبت برای هوای تهران بطور کلی حدود ۳۰ تا ۴۰ درصد میباشد و فقط در زمستان/پاییز تا حدود ۴۵ تا ۶۰ درصد افزایش میابد.
پس راههای افزایش رطوبت:
- ساخت جزیره (قرار دادن گلدان روی سینی/ظرف پر از آب و سنگریزه).
- غبارپاشی منظم (به جز برای گیاهان کرکدار و گوشتی).
- استفاده از دستگاه تولید بخار سرد.

6. تغذیه و کوددهی اصولی

کوددهی در فصل رشد (بهار و تابستان): هر ۴-۶ هفته یکبار با کود مایع رقیق شده.
کوددهی در فصل خواب (پاییز و زمستان): معمولاً نیاز به کوددهی نیست، چون رشد گیاه کند میشود و کمتر مواد مغذی مصرف می کند.
علائم کمبود مواد مغذی:
- زردی برگها (کمبود نیتروژن).
- لکه های قهوهای روی برگها (اگر بیماری نباشد).

7. مقابله با آفات رایج

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

8. هرس و تمیز کردن برگها

هرس: برگهای زرد و خشک را جدا کنید تا انرژی گیاه صرف رشد برگهای سالم شود.
تمیز کردن برگها: با یک دستمال مرطوب، گردوغبار را پاک کنید تا روزنه های برگها تمیز شوند و فتوسنتز بهتر انجام شود.

تصویر روزنه های روی برگ که گیاه بوسیله آنها تنفس/فتوسنتز انجام میدهد:

نکته اینکه هر گیاه شخصیت خاص خود را دارد و با مشاهده و تحقیق می توان نیازهای آن را بهتر درک کرد...

با رعایت این نکات، گیاهان سالمتر و شادابتر خواهند ماند.

۰ نظر

یوشا آل ایوب

قدیمی ترین مطالب مطالب قدیمی تر

مطالب جدید تر

یوشا

دست نوشته ها و تجربیات شخصی

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

نرم افزار

سیستم عامل

GNU/Linux

Android

Windows

برنامه نویسی

C

PHP

Net.

پایگاه داده و SQL

امنیت

سخت افزار

شبکه و وب

عمومی

Contents

Introduction

Types of packages

Characteristics of a package

The Laravel package!

Components of a Laravel package

Example of a Laravel package

Creating your Laravel package

Best practices

Publish your Laravel package

Conclusion

1. هنگام خرید گیاه: زیاد به توصیه های فروشنده اعتماد نکنید!

2. تعویض گلدان: عجله نکنید

3. انتخاب گیاهان مناسب برای افراد تازه کار

4. آبیاری صحیح: عامل اصلی مرگ گیاهان خانگی

5. تأثیر رطوبت و دمای محیط

6. تغذیه و کوددهی اصولی

7. مقابله با آفات رایج

8. هرس و تمیز کردن برگها