Das direkte Einbinden als Base64 Data-URL ist echt praktisch, aber man will ja nicht, dass die Benutzer nun endlos riesige Bilder darüber einbinden. Deswegen ist es eine gute Idee, die Bilder beim Einfügen auch gleich zu verkleinern. Das ist zum Glück mit dem Canvas-Element sehr einfach.
Die Callback-Function:
let onImageUploadFunc = function (elementId) {
return function(image) {
resizeImage(image[0], elementId);
}
};
function resizeImage(file, elementId) {
let image = new Image();
let url = window.URL ? window.URL : window.webkitURL;
image.src = url.createObjectURL(file);
image.onload = function (e) {
let canvas = document.createElement("canvas");
let ctx = canvas.getContext("2d");
let width = 600;
let factor = image.width / width;
let height = image.height / factor;
if(image.height > image.width) {
height = 300;
factor = image.height / height;
width = image.width / factor;
}
canvas.width = width;
canvas.height = height;
ctx.drawImage(image, 0, 0, canvas.width, canvas.height);
$(elementId).summernote('editor.insertImage', canvas.toDataURL('jpeg', 0.7));
};
}
Verwendung:
$('#editSolution').summernote(
{callbacks:{onImageUpload: onImageUploadFunc('#editSolution')}}
);
Manchmal muss man z.B. das Kopieren von Dateien auf einen Server per SCP testen. Oder auch einfache Deployments auf einem Server. Hier ist ein kleines SSH-Server Image mit Bash und Rsync.
FROM sickp/alpine-sshd:7.5
RUN apk update
RUN apk add bash
RUN apk add rsync
Und in einer docker-compose.yml
version: "3.0"
services:
ssh-server:
build: .
ports:
- "2222:22"
User: root
Password: root
Man kann aber auch authorized-keys hinterlegen, wie auf der Seite des Base-Images erklärt wird.
Ist es okay mit einem dreckigen Master-Branch zu starten?
Meiner Meinung nach ist es vollkommen ok. Ein leeres Projekt als stable zu deklarieren macht keinen Sinn und ist in den meisten Fällen auch nicht deploybar, da z.B. eine build.xml oder .gitlab-ci.yml noch fehlen.
Master mit dirty Commit vor dem ersten Release
Ich vertrete die Meinung, dass der Master erst nach dem ersten Release stable gehalten werden muss. Es folgt der Regel, dass im Master der letzte nutzbare Stand liegt. Wenn kein Release vorhanden ist, ist der letzte Commit der Dev-Version, die nutzbarste Version die man finden kann. In dem Sinne bemühe ich bei der Regel eine Art Fallback auf die Dev-Version, für die Zeit wo kein Release existiert. Nach dem ersten Release ist immer das letzte Release die nutzbarste Version.
Es gibt also immer eine nutzbare Version und nie "Nichts".
Dieser Post fußt auf meinen Post Git State Konzept.
Wenn ich in Ubuntu unter meinem Windows 10 Node.js und NPM installiere macht es nur Probleme. "npm install" beschwert sich dass 'in' unbekannt sei.
Momentan läuft es bei mir so am Besten:
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -
sudo apt-get update && sudo apt-get install -y nodejs
Dann funktioniert auch die Vue-CLI Installation:
npm install -g @vue/cli
npm install -g @vue/cli-service-global
Unter Windows direkt... da war alles noch schlimmer.
Eine Admin-UI lebt nicht nur von Tables sondern auch von sehr vielen Forms. Die möchte man ja nur ungern komplett per Hand bauen sondern etwas wie JSON-Schema benutzen, da man das auch auf Server-Seite für die Validierung nutzen kann.
CoreUI und vue-form-generator arbeiten gut zusammen.
Man muss vue-form-generator nur per NPM installieren.
<template>
<CRow>
<CCol col="12" md="6">
<CCard>
<CCardHeader>
JSON-Schema Form
</CCardHeader>
<CCardBody>
<vue-form-generator :schema="schema" :model="model" :options="formOptions">
</vue-form-generator>
</CCardBody>
<CCardFooter>
<CButton block color="primary">Submit</CButton>
</CCardFooter>
</CCard>
</CCol>
</CRow>
</template>
<script>
import Vue from 'vue'
import VueFormGenerator from 'vue-form-generator'
Vue.use(VueFormGenerator);
export default {
name: 'Alerts2',
data () {
return {
model: {
id: 1,
name: 'John Doe',
password: 'J0hnD03!x4',
skills: ['Javascript', 'VueJS'],
email: 'john.doe@gmail.com',
status: true
},
schema: {
fields: [
{
type: 'input',
inputType: 'text',
label: 'ID (disabled text field)',
model: 'id',
readonly: true,
disabled: true
},
{
type: 'input',
inputType: 'text',
label: 'Name',
model: 'name',
placeholder: 'Your name',
featured: true,
required: true
},
{
type: 'input',
inputType: 'password',
label: 'Password',
model: 'password',
min: 6,
required: true,
hint: 'Minimum 6 characters',
validator: VueFormGenerator.validators.string
},
{
type: 'select',
label: 'Skills',
model: 'skills',
values: ['Javascript', 'VueJS', 'CSS3', 'HTML5']
},
{
type: 'input',
inputType: 'email',
label: 'E-mail',
model: 'email',
placeholder: 'User's e-mail address'
},
{
type: 'checkbox',
label: 'Status',
model: 'status',
default: true
}
]
},
formOptions: {
validateAfterLoad: true,
validateAfterChanged: true,
validateAsync: true
}
}
}
}
</script>
Ja das ist einfach das Beispiel, das ich kopiert habe.... aber es funktioniert!
pecl install pcov && docker-php-ext-enable pcov
ausführen. Dann funktioniert die Installation und es steht für Unit-Tests zur Verfügung.
Braucht man zum Testen von Deploy-Usern in Gitlab-CI Jobs sehr oft:
ssh -i pk_file dummy@example.com
also i und nicht f wie beim ssh-keygen.. da komme ich irgendwie dauernd durch einander.
Falsch (Attributes sind CamelCase):
$cats = Shopware()->Modules()->Categories()->sGetMainCategories();
Richtig (Attribute mit Underscore):
$catId = Shopware()->Shop()->getCategory()->getId();
$cats = Shopware()->Modules()->Categories()->sGetCategories($catId);
bezahlt von 
