w: Lưu văn bản
wq: Lưu và thoát

Lỗi nhỏ: thiếu dấu : trước chữ w và wq bạn ơi

sau khi setup project Laravel bạn vui lòng chạy npm install nhé. Mình thấy ko cần thiết làm hẳn 1 bài về cách sử dụng npm, sử dụng Vue và các package liên quan mặc định cần sử dụng node modules. Một bài post mình không thể nhồi hàng tá kiến thức vào đó đc bạn à, trong khi npm bạn có thể search gg và tìm đc nhiều kết quả có ích hơn, mình không nên nói lại những điều đã có rất sẵn và tốt trên gg nhé b. Nếu bạn ko hiểu về npm mình sẽ share cho bạn một số nguồn để bạn tìm hiểu

Đúng rồi, Eloquent ORM phải bảo mật cao hơn chứ nhỉ.

Mình mặc định là các bạn đã tạo sẵn project bằng Laravel và đã chạy npm install nhé.

bạn có bài nào get started với npm không bạn?

@quynh001 anh nghĩ contracts (interfaces) có mục đích chính là giải quyết vấn đề tightly coupled trong logic của mình, nhất là với các component dạng driver-based. Nó sẽ thuận tiện khi em viết unit test chẳng hạn. Việc các interface không có đầy đủ các phương thức cũng có thể coi là một điểm trừ nhưng theo anh thì nó giống như trade-offs giữa sự đơn giản và tính đầy đủ ấy. Thôi thì không thích thì mình tự customize lại

QueryBuilder có tính bảo mật cao hơn Eloquent ORM trong việc phòng chống SQL Injection.

Tính chất này có vẻ không đúng bạn à

bạn nên đăng thêm thông tin cấu hình server với thông tin về web nữa thì mọi người mới tư vấn được. Nếu bạn k rành về server thì bạn có thể cài script của hocvps, quản lý khá tiện và nó tự động tối ưu các thông số cho mình.

Bác cho em hỏi sao em cứ thêm phần cấu hình ssl vào cái là HAproxy bị lỗi nhỉ, file cấu hình của em thế này có gì sai không?

global
    stats timeout 30s
	daemon	
	maxconn 1024
	
defaults
	mode http
	timeout connect 5000ms
	timeout client 50000ms
	timeout server 50000ms

frontend http-in
	bind *:80
	reqadd X-Forwarded-Proto:\ http	
	default_backend servers

#phần này cứ thêm vào cái là bị lỗi.	
frontend https
	bind *:443 ssl crt /etc/haproxy/ssl/file.pem		
	reqadd X-Forwarded-Proto:\ https
	default_backend servers

backend servers	
	balance roundrobin		
	server webserver1 xxx.xxx.xxx.xxx:8080 check
	server webserver2 xxx.xxx.xxx.xxx:82 check

wow, k giỏi đến thế đâu

mà thiệt tình mình không hiểu: Code ban đầu thế này:

function foo() {
    var a = 2;
    console.log(a);
}

function bar() {
    var a = 3;
    foo();
}

var a = 'Ahihi';
bar();

Đoạn code bên trên chẳng nhẽ không tương đương với đoạn dưới này sao:

function bar() {
    var a = 3;
    var a = 2;
    console.log(a);
}

var a = 'Ahihi';
bar();

Thế này , nếu bỏ var a = 2 đi thì bên trên vẫn còn var a= 3 mà, tại sao nó phải vượt ra hẳn bên ngoài để lấy a = Ahihi

Bác code bằng ngôn ngữ j v ?

@thangtd90 Laravel khai báo một danh sách các core aliases trong Illuminate\Foundation\Application

'session.store'        => [\Illuminate\Session\Store::class, \Illuminate\Contracts\Session\Session::class],

Dựa theo khai báo này, khi muốn làm việc với Session mà muốn type-hint thay vì sử dụng helpers hay Facade thì rõ ràng em nên type-hint interface lluminate\Contracts\Session\Session. Mà interface này thì không có method flash.

@thangtd90 Trong trường hợp này, integration services mà em nói chính là helpers và facades mà Laravel đã viết đó anh. :v Em thích phong cách code rõ ràng hơn.

@buihieubthc2rb người gì đâu vừa xinh lại vừa giỏi :-?

@quynh001 Đoạn trên thì cũng không hẳn là type hint, mà chỉ là comment cho kiểu của biến thôi (^^;) nhưng đúng là nên để tên class Illuminate\Foundation\Application ở đây thì hơn =))

Khi viết một package, chắc chắn không nên sử dụng integration services từ package khác mà nên dùng dependencies, ngay cả khi package chỉ phục vụ cho một framework duy nhất. Em nghĩ tốt nhất là như vậy.

Câu này thì anh không hiểu lắm (^^;)

Em tìm hiểu thì thấy lluminate\Contracts\Session\Session thì không có method flash. Flash chỉ có trong concrete mặc định của nó là Illuminate\Session\Store.

Cái này thì đúng là có vấn đề (^^;), một là em không type hint interface nữa, gọi helper của laravel thôi :v Type hint interface thì không nên gọi hàm không có trong interface đó

Mà em thì chọn cách type-hint interface, nó thuận lợi cho việc mở rộng và dễ test hơn.

Anh cũng nghĩ vậy, type hint thì nên là interface

@thangtd90 Typehint chính là vấn đề mà em gặp phải, mà nguồn Laravel đã quá "linh động"

Kì thực, nếu chúng ta chỉ sử dụng concrete mặc định mà không thay đổi thì chẳng có vấn đề gì cả.

• Nhưng đây là constructor của ServiceContainer

/**
 * Create a new service provider instance.
 *
 * @param  \Illuminate\Contracts\Foundation\Application  $app
 * @return void
 */
public function __construct($app)
{
    $this->app = $app;
}

• Laravel đã typehint interface Application nhưng lại sử dụng method từ concrete mặc định của nó. Em không thích cách làm như thế. Đây chỉ là ví đụ nhỏ em thấy. Còn nhiều trường hợp typehint khác mà ông Taylor vẫn chấp nhận điều tương tự. Đó là lý do của tác giả, em chỉ thắc mắc chút thôi.

Cụ thể, vấn đề của em gặp phải như sau:

• Khi viết một package, chắc chắn không nên sử dụng integration services từ package khác mà nên dùng dependencies, ngay cả khi package chỉ phục vụ cho một framework duy nhất. Em nghĩ tốt nhất là như vậy.

• Trong package của mình, em cần sử dụng type-hint Session interface và cần sử dụng method flash.

• Em tìm hiểu thì thấy lluminate\Contracts\Session\Session thì không có method flash. Flash chỉ có trong concrete mặc định của nó là Illuminate\Session\Store.

• Như vậy, hoặc thay vì type-hint interface, em phải type-hint concrete hoặc em cần tự khai báo một interface mới có method flash.

• Mà em thì chọn cách type-hint interface, nó thuận lợi cho việc mở rộng và dễ test hơn.

Khi mà chạy hàm foo() và console.log(a); nhưng không tìm thấy variable a trong scope của foo, javascript engine sẽ tìm outer scope (hay parent scope), tức là scope mà bao cái scope foo. Ở đây, parent scope của foo chính là global scope, ở đây biến a được khai báo là var a = 'Ahihi' nên hàm console.log(a); sẽ cho ra kết quả là Ahihi.

Lý do mà parent scope của foo là global scope chứ không phải scope mà bar(); (mặc dù hàm foo() được gọi bên trong bar()) là do việc quyết định scope nằm ở lúc compile, chứ không phải lúc excute. Khi compile thì javascript engine chỉ quan tâm tới declaration, tức là, scope và parent scope của một function sẽ quyết định khi mà nó được khai báo (declaration).

Hàm foo() và bar() đều được khai báo, sao cho outer scope, hay parent scope của nó, là global. Nên bỏ phần khai bảo bên trong local scope của mỗi function đi thì giá trị a in ra sẽ là giá trị global var a = 'Ahihi';

@pht Cảm ơn anh đã hiểu câu hỏi của em và nêu ra những ví dụ khác liên quan để thấy vấn đề rõ ràng hơn.

Nhìn chung, em nghĩ đi dùng "hàng" của người khác thì phải chấp nhận làm theo hướng dẫn sử dụng của họ.

Thôi thì code cũ chạy ngon thì kệ nó, mình viết code mới thì tạo contract mới thôi. Không lại gặp trường hợp vào đọc container, rồi viết một class khác implements đúng interface, quay ra thấy "method not exist" thì mệt lắm.

Lỗi typo nhiều lắm ==

Bạn code gì trên notepad ? Bạn là font-end ?