Chelsie  Towne

Chelsie Towne

1593315780

Useful JavaScript Tips — Objects and Scopes

In this article, we’ll look at some tips we should follow to write JavaScript code faster and better.

Polluting Global Scope

We should never define global variables to declare the global scope.

To avoid this, we use let and const to declare variables.

For instance, we write:

ler x = 1;

or:

const y = 2;

We shouldn’t declare variables with var or without a keyword before it.

They both declare global variables, which we don’t want.

Likewise, we should not use function declarations.

Instead, we should use function expressions.

So instead of writing:

function foo() {}

We write:

const foo = () => {}

We can also enclose our variables within IIFEs to keep them private:

(() => {
  let  = 1;
})()

Now they are not accessible outside the function.

Use Strict Mode

We should use strict mode to disallow some bad constructs in our code.

For instance, we can’t assign things to reserved keywords like:

undefined = 1;

Also, we can’t accidentally define global variables by assigning to variables without declaring them.

So we can’t create global variables like:

foo = 1;

foo is a global variable since we declared it without a keyword.

#javascript

What is GEEK

Buddha Community

Useful JavaScript Tips — Objects and Scopes
Arvel  Parker

Arvel Parker

1591611780

How to Find Ulimit For user on Linux

How can I find the correct ulimit values for a user account or process on Linux systems?

For proper operation, we must ensure that the correct ulimit values set after installing various software. The Linux system provides means of restricting the number of resources that can be used. Limits set for each Linux user account. However, system limits are applied separately to each process that is running for that user too. For example, if certain thresholds are too low, the system might not be able to server web pages using Nginx/Apache or PHP/Python app. System resource limits viewed or set with the NA command. Let us see how to use the ulimit that provides control over the resources available to the shell and processes.

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

MEAN Stack Tutorial MongoDB ExpressJS AngularJS NodeJS

We are going to build a full stack Todo App using the MEAN (MongoDB, ExpressJS, AngularJS and NodeJS). This is the last part of three-post series tutorial.

MEAN Stack tutorial series:

AngularJS tutorial for beginners (Part I)
Creating RESTful APIs with NodeJS and MongoDB Tutorial (Part II)
MEAN Stack Tutorial: MongoDB, ExpressJS, AngularJS and NodeJS (Part III) 👈 you are here
Before completing the app, let’s cover some background about the this stack. If you rather jump to the hands-on part click here to get started.

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

systemctl List All Failed Units/Services on Linux

Is there is a command to print list all failed units or services when using systemd on Linux? Can you tell me the systemctl command to list all failed services on Linux?

This quick tutorial explains how to find/list all failed systemd services/units on Linux operating systems using the systemctl command.

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

Brain  Crist

Brain Crist

1595434320

Docker Applikationen mit Visual Studio Code debuggen

Mit dem integrierten Debugger von Visual Studio Code lassen sich ASP.NET Core bzw. .NET Core Applikationen einfach und problemlos debuggen. Der Debugger unterstützt auch Remote Debugging, somit lassen sich zum Beispiel .NET Core Programme, die in einem Docker-Container laufen, debuggen.

Als Beispiel Applikation reicht das Default-Template für MVC Applikationen dotnet new mvc

$ md docker-core-debugger
$ cd docker-core-debugger
$ dotnet new mvc

Mit dotnet run prüfen wir kurz, ob die Applikation läuft und unter der Adresse http://localhost:5000 erreichbar ist.

$ dotnet run
$ Hosting environment: Production
$ Content root path: D:\Temp\docker-aspnetcore
$ Now listening on: http://localhost:5000

Die .NET Core Applikation builden wir mit dotnet build und publishen alles mit Hilfe von dotnet publish

$ dotnet build
$ dotnet publish -c Debug -o out --runtime linux-x64

Dabei gilt es zu beachten, dass die Build Configuration mit -c Debug gesetzt ist und das Output Directory auf -o out. Sonst findet Docker die nötigen Binaries nicht. Für den Docker Container brauchen wir nun ein Dockerfile, dass beim Start vorgängig den .NET Core command line debugger (VSDBG) installiert. Das Installations-Script für VSDBG ist unter https://aka.ms/getvsdbgsh abfrufbar.

FROM microsoft/aspnetcore:latest
WORKDIR /app

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       unzip procps \
    && rm -rf /var/lib/apt/lists/* \
    && curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l /vsdbg

COPY ./out .
ENTRYPOINT ["dotnet", "docker-core-debugger.dll"]

Den Docker Container erstellen wir mit dem docker build Kommando

$ docker build -t coreapp .

und starten die Applikation mit docker run.

$ docker run -d -p 8080:80 --name coreapp coreapp

Jetzt muss Visual Studio Code nur noch wissen, wo unsere Applikation läuft. Dazu definieren wir eine launch.json vom Typ attach und konfigurieren die nötigen Parameter für den Debugger.

{
    "version": "0.2.0",
    "configurations": [
         {
            "name": ".NET Core Remote Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickRemoteProcess}",
            "pipeTransport": {
                "pipeProgram": "docker",
                "pipeArgs": ["exec", "-i coreapp ${debuggerCommand}"],
                "quoteArgs": false,
                "debuggerPath": "/vsdbg/vsdbg",
                "pipeCwd": "${workspaceRoot}"
            },

            "logging": {
                "engineLogging": true,
                "exceptions": true,
                "moduleLoad": true,
                "programOutput": true
            },
        }
    ]
}

Mit F5 starten wir den Debugger. Wenn alles klappt, sollte eine Auswahl der Prozesse des Docker-Containers sichtbar sein.

vscode

Nun muss der dotnet Prozess ausgewählt werden. Der Visual Studio Code Debugger verbindet sich darauf mit VSDBG und wir können wie gewohnt unseren Code debuggen. Dazu setzen wir einen Breakpoint in der Index-Action des HomeControllers und rufen mit dem Browser die URL http://localhost:8080/ auf.

vscode

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

Yoshiko  Jones

Yoshiko Jones

1598195340

How to configure AWS SES with Postfix MTA

How do I configure Amazon SES With Postfix mail server to send email under a CentOS/RHEL/Fedora/Ubuntu/Debian Linux server?

Amazon Simple Email Service (SES) is a hosted email service for you to send and receive email using your email addresses and domains. Typically SES used for sending bulk email or routing emails without hosting MTA. We can use Perl/Python/PHP APIs to send an email via SES. Another option is to configure Linux or Unix box running Postfix to route all outgoing emails via SES.

  • » Remove sendmail
  • » Install postfix
  • » Configuring postfix for SES
  • » Test postfix

Procedure to configure AWS SES with Postfix

Before getting started with Amazon SES and Postfix, you need to sign up for AWS, including SES. You need to verify your email address and other settings. Make sure you create a user for SES access and download credentials too.

Step 1 – Uninstall Sendmail if installed

If sendmail installed remove it. Debian/Ubuntu Linux user type the following apt command/apt-get command:

$`` sudo apt --purge remove sendmail

CentOS/RHEL user type the following yum command or dnf command on Fedora/CentOS/RHEL 8.x:

$`` sudo yum remove sendmail

$`` sudo dnf remove sendmail

Sample outputs from CentOS 8 server:

Dependencies resolved.
===============================================================================
 Package           Architecture  Version               Repository         Size
===============================================================================
Removing:
 sendmail          x86_64        8.15.2-32.el8         @AppStream        2.4 M
Removing unused dependencies:
 cyrus-sasl        x86_64        2.1.27-1.el8          @BaseOS           160 k
 procmail          x86_64        3.22-47.el8           @AppStream        369 k

Transaction Summary
===============================================================================
Remove  3 Packages

Freed space: 2.9 M
Is this ok [y/N]: y

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]