Ik zag iemand op Twitter die zei: nu ik op Windows zit, mis ik Preview.app. Want dat opent allerlei formaten zonder last.
Dat is zo, en het doet nog meer. Je kan PDF’s los van elkaar trekken. Je kan PDF pagina’s combineren. Je kan je handtekening digitaal zetten. Je kan PDF’s annoteren.
Je kan een slideshow maken van een hoop JPGs. Je kan een PDF presenteren als slideshow. Er zit heel wat “verborgen” functionaliteit in Preview.app. Van die handige dingen waarvan je niet beseft dat ze geweldig zijn tot je ze moet missen.
(Blog post gecategoriseerd onder: redenen waarom ik niet zo snel naar Windows zou switchen.)
Kenneth Tits heeft het over een cookie banner die je laat wachten als je de cookies niet accepteert, en dit bij Proximus. Peter Fransen geeft als repliek een voorbeeld van VRT NWS waar ik mij ook al aan laten vangen heb.
Dit zijn nu net twee overheidsbedrijven die voor mij het goede voorbeeld moeten geven. Maar wat zij doen is een dark pattern toepassen. Een truukje om je de keuze te laten maken die hen het beste uitkomt.
Ik vind dat een trieste zaak. Deze sites moeten juist het goede voorbeeld geven.
Er stond een tijd een goede demo van de OCR-capaciteiten van Microsoft’s Cognitive Vision API op deze URL.
Ik had die URL goed opgeslagen want ik ben die tool eigenlijk regelmatig beginnen gebruiken om echte data in mijn ontwerpen te krijgen. Het was voor mij de eerste OCR die echt goed werkte.
Ik gebruikte het vaak om van een screenshot naar echte bewerkbare lagen in Figma te gaan. Maar vandaag zag ik dat Microsoft hun site heeft herontworpen, en nu is de demo een andere demo: namelijk het deel van de Cognitive Vision API dat gezichten en andere dingen herkent op foto’s. Heel tof allemaal, maar niet wat ik nodig heb.
Wat doen we dan? Het tooltje opnieuw bouwen. Aldaar.
Nu zou ik daar graag rechtstreeks een bestand op kunnen droppen in plaats van iets te moeten uploaden. Maar dat is iets voor als ik nog eens te veel tijd heb.
Ik hoorde op de radio dat Hilde Crevits claimde dat “bedrijven nog steeds geld blijven krijgen voor opleiding”. Dit in de context van een besparing van 23 miljoen op de KMO portefeuille.
Dit is een fundamentele onwaarheid die ik even recht wil zetten. Bedrijven krijgen helemaal geen geld voor opleidingen. Ze krijgen enkel een korting op een door de overheid erkende opleiding, terwijl het hele bedrag van de opleiding terug vloeit naar het bedrijf zelf.
Het statement van Mevr. Crevits klinkt bijna alsof wij als bedrijf een bedrag van de overheid krijgen om opleidingen mee te betalen. Waar het over gaat is dat je 40% korting kan krijgen krijgen opleidingen die onder de KMO portefeuille vallen.
Dit zijn opleidingen die wij toch niet kopen, dus voor ons bedrijf is dit compleet irrelevant. De betere conferenties rond mijn vakgebied zijn tot nu toe jammer genoeg altijd in het buitenland geweest.
Hoe werkt die KMO Portefeuille? Als onderneming kan je erkend worden als dienstverlener. Dit is een proces waar je moet bewijzen dat je aan een aantal voorwaarden voldoet. Dit is een ingewikkeld proces, ingewikkeld genoeg dat er eens reeks consultants is opgesprongen om dit aan te bieden voor ca. 3000 euro (om dan erkend te worden voor een periode…).
Als je dit doet, dan kan je 40% terug krijgen op een opleiding als deelnemer. Wat bedrijven dan kunnen doen is de opleiding gewoon duurder maken en het verschil in eigen zak steken. De maatregel schiet zijn doel dan compleet voorbij. Zelfs als ze dat niet doen, en de 40% korting gewoon geven op de normale prijs, wordt er een oneerlijk speelveld gecreëerd tussen diegenen die wel willen investeren in de KMO portefeuille en alle bijkomende administratie die daarbij komt.
Een gelijkaardige situatie bestaat bij VLAIO projectsubsidies (vroeger IWT). Er zijn diegenen die mee willen stappen in het verhaal van een (universitaire) partner vinden, met meerdere bedrijven samen werken – en het ergste – hun ideeën periodiek moeten valideren voor een commissie die er toch niets van snapt – om een stukje van de overheidspot te verkrijgen. Voor vele startups is dit gewoon een overbodig blok aan hun been. Het is bijna het tegenovergestelde van een startup zijn.
Je gaat bij de overheid bedelen om een beetje geld om te kunnen ondernemen. Waar ben je dan eigenlijk mee bezig als startend bedrijf? In plaats van een lange subsidieaanvraag in te vullen (al dan niet met wederom de hulp van een dure consultant) zou je beter bezig zijn met je eerste klanten te vinden en een goed product te bouwen.
Dat geld is dan ook meteen de enige reden om mee te doen. Ik heb nog nooit iemand gehoord die mee doet omdat hij of zij het een goede formule vind. Als iemand de formule aan mij wil verdedigen hoor ik dat graag. Mijn mailbox staat open.
Omdat wij software ontwerpen en vele innovatieprojecten zich in de software bevinden, komen wij de bedrijven soms tegen als mogelijke klanten. Ik ben er ook zeker van dat ik al in minstens 2 of 3 projecten heb gewerkt waar het geld uit een overheidspot komt. Ik heb een tijd terug met lede ogen gekeken naar een lijst van IWT subsidies (ik denk uit 2015) waar een hele reeks bedrijven geld kregen voor een “innovatief” project voor iets wat ze toch sowieso gingen doen.
De twee die ik onthouden had was een Barco die 3.3 mio subsidies kregen. Alsof Barco nog subsidies nodig heeft… de 2e beste vond ik een hosting bedrijf dat 220.000 euro kreeg om een nieuw control panel te ontwikkelen. Hallo? Heb je dat niet sowieso nodig als hosting bedrijf?
Je zou kunnen argumenteren dat dat een goede subsidiepot ons als agency/consultancybedrijf in software goed uitkomt. Mijn betoog gaat erover om de subsidiepot sterk in vraag te stellen. Dit is dus letterlijk tegen onze winkel.
Waarom? Waar dit betoog mij over gaat is een eerlijk speelveld creëeren waar je als ondernemer de kans hebt om iets uit te voeren. Zonder dat op je knieën moet gaan voor een IT-reus. Zonder dat je naar Brussel gestuurd wordt om een reeks ambtenaars uit te leggen dat je innovatief project een kans op slagen heeft.
Om terug te komen op waar het geld dan voor gebruikt wordt. Ik zie dan vaak dat het geld gebruikt wordt voor een kost die het bedrijf sowieso ging maken. Maar de ergste situatie is diegene waar het bedrijf het geld eigenlijk niet nodig heeft en er dan maar iets pseudo-innovatiefs mee doet.
De regelingen rond bedrijfssubsidies zorgen voor een oneerlijk speelveld. Wat ik wil als ondernemer is een lagere vennootschapsbelasting, zodat ik het geld dat ik verdien kan herinvesteren.
Als er van elke 100 euro winst 34 euro wordt afgeroomd duurt het lang eer ik een spaarpotje heb om te investeren. Geld dat in een bedrijf kan blijven heeft een hefboomeffect dat ervoor zorgt dat je ermee kan ondernemen. Het interesseert me nog niet zozeer hoeveel het dan kost om dat geld dan uit te keren naar privé. Ik wil geld om te investeren in de groei van een bedrijf en de goede dingen die ik hier mee kan bewerkstelligen.
De overheid zou in mijn ogen beter de vennootschapsbelasting in het algemeen verlagen in plaats van cadeau’s uit te delen aan diegenen die door de administratieve winkel willen gaan (KMO Portfeuille) of zich willen binden in een verhaal dat totaal naast de kwestie is (VLAIO projectsubsidie).
Er is nu 23 miljoen van het budget van de KMO portefeuille. In mijn ogen mag deze maatregel volledig afgeschaft worden. Met wat ik er momenteel over weet zie ik er niets positiefs in. De afschaffing van deze maatregeling zal zorgen voor een kleinere overheid, en een eerlijker speelveld wat betreft privé-opleidingen.
Door een combinatie van overheidsbeslissingen creëert de overheid een landschap van proberen verkrijgen van projectsubsidies, in plaats van een landschap van ondernemers die het heft in eigen handen nemen om te doen waar ze goed in zijn: ondernemen.
Geef ondernemers de vrijheid om te ondernemen en belast ze niet met allerhande goedbedoelde maatregelen die hun doel compleet missen. Creëer een eerlijk speelveld voor alle ondernemingen. Zit niet overal tussen, zodat je het overheidsbeslag kan verlagen. En wie weet komen we dan ooit eens aan een verlaging van de belastingen. Zou dat niet iets zijn?
I looked deeper into Tailwind this weekend. I was aware of this framework and its popularity, but I wanted to dive deeper into it as I was researching it for a future project.
If you have to choose your CSS strategy in 2019, there are different options:
Use a framework that “comes with everything”: frameworks like Bootstrap / Foundation / Fomantic UI / …
Work with a utility first framework like Tailwind (…there’s probably others?)
Custom: build it yourself
A combination of the above
… (and probably something else I forgot now)
And then, in regards to coding strategies, there are different techniques:
Just keep on adding CSS (would not really consider this a strategy…!)
Use something like styled-components or emotion to have CSS-in-JS – which puts you on an entirely different path. And which is definitely something you want to avoid, but that is a topic in itself.
For development speed purposes, a framework is a good thing, especially if it has an underlying layer of Javascript components that are well maintained (I am thinking about the more complex things like datepickers, popovers, etc.)
First up is a disclaimer, I am by no means experienced with Tailwind – I am merely looking into whether it’s a good idea to invest time in it in the first place.
Feel free to counter my arguments in the comments and let’s make it a conversation.
What is Tailwind? What’s the coding strategy?
Tailwind is not as opinionated as most frameworks. It is a set of customizable classes, almost like a set of pre-defined design tokens that you can then use to customize your UI.
This is interesting, especially if you create lots of different things with different looks. You can then change the tokens based on the project you are working on but use similar code to lay out responsive designs.
The general code strategy is to use lots of utility classes to build up a component, for example (from the Tailwind homepage):
This code strategy leads to new problems, especially when used at scale. Most notably the problem with Tailwind is that your template code is littered with CSS classes. Below is an actual example from the docs for a simple card component.
In my opinion this template code already looks complex, and there is not even any logic going on. So a real-life template could become a bit of a monster. And a real-life template is just one of hundreds in a web app codebase.
In the Tailwind documentation there is a page called “extracting components” which talks about strategies to counter this problem. This is good as it shows the framework authors are aware of the disadvantages of their methodology.
The first method the author argues for is to simply extract the code into a component, for example if you are using Vue, you would create a new Vue component and then put the markup in that component. In the “overview” page you can then run v-for loop so the markup for something like 6 items becomes 1 item. The author claims the code is clean enough that way, and the right abstraction is made.
This might be the logical for some situations, but I am not sure about this for the reasons stated above – real world templates are just simply more complex than the stated examples. At least they are in the apps I am working on. However, your mileage may vary; I heard on Twitter that some people were very happy with Tailwind, but then they pointed to their small-ish websites as proof.
The second method for reducing complexity is using something called @apply. This is a Tailwind-specific thing where you use @apply to combine Tailwind utilities into its own CSS class.
For example:
.btn {
@apply font-bold py-2 px-4 rounded;
}
This would then make .btn available as a CSS class, with the consistent design tokens. The processing for this is done with PostCSS.
I think this is interesting but then I worry about how this actually simplifies my code.
Here is some button code from a recent project. This is BEM/ITCSS based. Warning, it is quite long. First up is just the layout code, this is not even about the different variants of the button. I made the code boxes scrollable so you can scan this blog post.
If we were to rewrite this last CSS partial to Tailwind, we might end up with something like this:
/* ==========================================================================
Component: Button Skins
---
Rules of this file: you CAN'T touch the box model here, just colors.
========================================================================== */
/* General
========================================================================== */
.c-button {
transition: 0.18s background ease-in;
}
/* Primary
========================================================================== */
.c-button.c-button--primary {
@apply no-border bg-indigo-600 color-white;
svg * {
fill: #FFF;
}
&:hover,
&:active,
&.c-button--active,
&:active:focus,
&.c-button--active:focus {
@apply bg-indigo-700;
}
}
/* Secondary
========================================================================== */
.c-button.c-button--secondary {
@apply border-indigo-600 bg-none color-indigo-600;
svg * {
@apply fill-indigo-600 // Q: How would I reference this variable in a way that works with the framework? Would I now have to make a set of fill utility classes?
}
&:hover,
&:active,
&.c-button--active,
&:active:focus,
&.c-button--active:focus {
@apply color-indigo-200;
}
}
}
I can’t help but wonder where this kind of code change actually helps us. With the @apply rules you the order of the CSS specificity is much harder to see. You get into niche issues – like, is there a utility class for SVG fill? Does @apply even parse in nested SCSS? (I guess not, and you would have to convert all code to PostCSS logic?)
I really don’t see how @apply would really help to improve the code to make it more legible or understandable. The only thing I can think of is that your design tokens stay consistent, but that’s what we have SCSS variables or native CSS variables for.
Default payload + controlling file size
The payload of Tailwind.css is +-475kb (huge!), which then they advice you can cut down by using PurgeCSS, a project to automatically cut down on the CSS used by scanning templates with a regex (More info can be found on the docs page about controlling file size.)
My first reaction was that I sort of object to this way of working. Automatic removal of CSS can lead to bugs and untestable code.
My feeling is that a real life codebase is just not as simple as scanning a few .html templates for whether a class occurs or not. Template code can come from a variety of places, it can get inserted dynamically through JS, you might build up class names dynamically… in my mind there is no way that a simple template scan can lead to good code.
Just to understand which perspective I am talking from I will talk a bit about my projects. The framework I am working with currently powers over 50 projects. The last project I did was a monolothic web app with over 50 modules (not 50 templates, 50 different modules of functionality, so we are talking hundreds of templates).
What if I fix a bug that only occurs inside an @print media query like I did just a few days ago? How sure am I that its code will remain in the CSS after running PurgeCSS? What if there is a bug in PurgeCSS? I find this a bit dangerous.
But! There is a big but. Eliminating dead code is super interesting. If you would be able to automatically remove the right code, then that is super great. If you would get hints about which code can be safely removed, that is also very cool.
I would need to know more about the PurgeCSS project and look more into it and how well maintained it is to make a final decision. From looking at the docs site it actually looks like quite a mature project, so the jury is still out.
What speaks for Tailwind: better customizability
All frameworks are made from a need, and a framework like Tailwind can definitely be helpful in a lot of cases.
I think it is immensely helpful to make sure people default to good design choices. Especially if you are not that design-savvy this is great. The flipside is that you end up with something that looks very default.
Tying in to the typical client wish for our agency projects to have a platform that looks branded, and incorporates just enough of the brand – a framework that (a) looks very – default – and (b) that is actually quite hard to customize will work against us.
The fact that you can customize Tailwind by first putting in the right design tokens makes a lot of sense. You can customize frameworks like Bootstrap, but “not really”, in a sense that the skinning mechanism only goes so far. By tokenizing your design logic (i.e. padding is multiples of 8, colors are x, y and z) you can basically -really- customize a design instead of putting a slight visual change on a framework.
Bootstrap vs. Tailwind when it comes to the resulting look
Using Bootstrap we have a problem: the project will look too much like Bootstrap. Bootstrap comes with a specific default look, which you might to avoid specifically if you have custom brand needs.
If you deliver custom designs (e.g. fully custom designs made in a design app like Figma) and then compare that to the standard look of Bootstrap, decide on Bootstrap as the base framework, you now have to marry the two. No matter how much work you put into it, the standard look of Bootstrap will always shine through. It seems like with Tailwind, you can entirely avoid that problem by using your own set of design tokens.
PostCSS and its stability
There’s other smaller reasons why I worry that Tailwind as a technology is not the best choice. It depends on PostCSS which is not as mature as SCSS. In fact, when I tried to install a PostCSS plugin for VSCode the first one I found was from an author who said she will no longer maintain it as she moved back to Sass/SCSS ?.
My Friday night experiment night led me to a lot of unfinished Github projects, niche issues with PostCSS, PurgeCSS combined with Vue etc.
I feel like these are not the kind of choices you want to make when you are developing a new project and you want the codebase to have some kind of longevity.
Stable ground
For any web app codebase you will want to use stable ground, frameworks that have proven themselves, and then customize that.
Bootstrap is a great example of a framework that I have extensive experience with and that has proven itself over and over again for a good CRUD app. I am coming back to what I stated in the beginning of this post, a framework is powerful especially if it has an underlying layer of Javascript components that are well maintained.
In our position as an agency delivering different solutions for different clients we will never have the time to dive so deep into every detail as the Bootstrap team did over the years.
It is naive to think that if your project is 2 months long that you can do better than an open source project that has been worked on for 5+ years with thousands of contributors.
My preferred methods – a bit about BEM/ITCSS
I have very good experiences with BEM/ITCSS, so that’s where I am coming from, and that’s what I am comparing Tailwind based CSS against.
A good BEM/ITCSS codebase is probably anyone’s best bet for the most custom look and to build upon for the future. But it does require certain skills to make it.
BEM is a set of manual code conventions, and requires some specific knowledge to be able to follow. Not just any dev in the team can typically do a good job in a BEM environment. In my experience, in any dev team there’s only a small percentage of developers who are really into that front-end part and who really get how to write proper BEM-based CSS.
Many developers simply don’t understand how to do it properly. That’s the reality out there. And we can’t be naive to that fact. It is because BEM is too hard to understand? Is it because too many people write production CSS when they really shouldn’t given their skillset? I don’t know, but I see a lot of bad BEM-based code, and that makes me think.
I still believe it is one of the best methods to deliver a good code base. The reasons why are varied and I would have to explain the whole ITCSS metholody to make sense of it. This blog post is already way too long, so I am just going to focus on one aspect.
If you have to start your project today, and you start with BEM/ITCSS, you can easily simplify the logic if you have scoped components in the future, because the right abstractions are already made (1 CSS file per component ).
E.g. with BEM style CSS you could start with SCSS partials in your main SCSS file e.g. main.scss:
These are the styles for a single component (where .c- is a custom namespace for components)
As the web will move on to newer tech, this can become simpler.
For example, if you have a compiler like in Svelte that automatically scopes the styles to a component (a trend that I can see become really popular next 1-2 years), the code from the original BEM/ITCSS component can simply become:
.component-child { }
.component-child--state { }
So, without the namespacing, but still with the double dash (--) naming convention for --state – because it still makes sense to see the difference.
So my point is that you can easily refactor a BEM/ITCSS based codebase to a styles-per-component style codebase in the future.
In some cases, depending on the framework, you could even do away with giving everything a CSS class. Here’s a link to a Svelte component where all the styles are very simple, just because they are scoped to its own component. This is not unique to this REPL, it’s the case for every Svelte component.
With the kind of CSS scoping provided by the compiler you can even directly style <button> in a component itself which is awesome for custom components. No more inventing of the umpteenth variation of a button and giving it a specific name.
(Do note this example is just a code example, a real finished component would be prettier.)
I believe this kind of CSS scoping is the future, but while Svelte is only now getting popular, and we need to ship code today, sticking to BEM/ITCSS for a while is a logical thing.
Especially because it is not tied to any given JS framework, and because of its set of conventions you can easily refactor it to a simpler version if called for; you could do a global search on all .c- substrings within all _(.*).scss partials and you would be literally done in minutes to simplify the code.
Now, what does all of the above have to do with Tailwind? Well, if you litter hundreds of templates with hundreds of utility classes, you are pretty much ****** if you ever decide to refactor the codebase.
That would be one of my main worries with Tailwind, and that’s why I would probably only use it for smaller projects.
The problem then is that for smaller projects, I don’t want the burden of a framework – I will just write things custom, even in plain CSS, not even using SCSS, and be much faster.
The point of a framework is re-use. But then again, Tailwind is maybe not a traditional framework, but it does come with the “stack burden” of a framework (e.g. a specific way of compiling and cleaning your CSS).
I am aware that I have other “resources” than a single developer (I am a designer – we have a whole design team that can come up with good designs) so I can definitely see the usage for a developer who is not that design-savvy.
Conclusions
Like most technology choices, Tailwind has things going for it and comes with its own set of disadvantages. I am not entirely convinced but the framework is interesting enough that it triggered me to write this super long blog post, so that’s something.
There are definitely good ideas in there and I will have to use the framework in practice to come up with a more conclusive opinion.
Ik heb een tijd geleden online een gast leren kennen die bij Netlify werkt, die een hele interessante filosofie heeft: #learninpublic. Het komt er op neer dat hij op zijn blog vanalles post, screencasts maakt met uitleg, en door het gesprek errond veel bijleert, maar tegelijk anderen inhoud geeft waar zij uit kunnen bijleren.
Ik vind dat een intrigerende manier om om te gaan met de complexiteit van web development. Als je er van uit gaat dat niemand het grote gelijk heeft, dat iedereen ook maar aan het leren is, en dan deelt waar je mee bezig bent, dan kan iemand anders daar van leren.
Voor mij heeft november een beetje een React-thema. Daar wil ik wat meer over bijleren. De resources rond Svelte zijn beperkt en ik wil weten hoe je productief in een React codebase kan werken.
De insteek is een betere deliverable. Je kan met HTML/CSS templates maar zo ver gaan… en dan moeten die nog vertaald worden naar een front-end framework. Ik heb me lange tijd afzijdig gehouden van daar in te werken (met de logica “dat is voor de programmeurs” of “wij doen enkel het presentational deel”), maar ik voel nu de nood om er toch in te investeren om uiteindelijk een betere UI te kunnen afleveren.
Zeker omdat wij zien dat ons prototypes soms té lang blijven leven als 2e codebase, met alle maintenance vandien, wat volgens mij niet gezond is. Het voordeel daaraan is dan weer dat die tot nu toe niet de framework-du-jour volgen (yay for permanence), maar aan de andere kant valt sommige CSS-logica — BEM/ITCSS om maar iets te noemen — ook compleet weg afhankelijk van je framework en zijn capaciteiten (e.g. dead code removal, automated CSS scoping).
Binnenkort komt Bram een workshop geven om ons React-niveau wat op te krikken. Daarnaast ben ik vorige zaterdag begonnen aan deze React: Creating and Hosting a Full-Stack Site. Ik heb de talk over React Hooks bekeken. Als iemand nog aanraders heeft, is dat zeker welkom. #learninpublic
In de vorige episode ging het nog over verschillende games testen, waarna ik uiteindelijk op Gran Turismo Sport was geland.
Dat is het spel dat ik de laatste tijd het meest gespeeld heb.
David Perel, mijn huidige raceheld (check zeker de man zijn YouTube kanaal) , zei eens dat sim racen een beetje is zoals trainen. Hoe meer je traint, hoe beter je wordt.
Ik heb dat ter harte genomen, en ik “train” dus op mijn sim racen om telkens beter te worden. Ik ben ook real-life beginnen trainen maar dat is een ander topic.
Een deelaspect van beter worden is volgens mij analyse van je werkpunten. Daarom ben ik begonnen met video’s te maken, om duidelijk te kunnen zien waar ik bv. een slechte rijlijn neem of waar ik iets sneller zou kunnen zijn.
Vorige week maakte ik deze video over de Daily Race B.
Gran Turismo – Daily Race B – Dragon Trail Seaside – 1:30:806
Toen heb ik gemerkt dat als je de input (brake/acceleration) niet kan zien dat het niet zo nuttig is om een filmpje te hebben. Dat kan beter dacht ik. Vandaag maakte ik een 2e filmpje waar je de inputs op kan zien.
First online victory at Suzuka (Daily Race B.)
In deze video geef ik uitgebreid commentaar op een race. Voor mij is dit ook weer een manier om wat bij te leren over video’s bewerken.
Het lastige hier is dat je dus constant je PS4 beeld moet opnemen via de “broadcast gameplay” functie. Er bestaan ook van die Elgato bakjes, maar dat is weer een kostelijke affaire.
En hetgene mij daar vooral in tegenhoudt is dat je dan ook een ontvanger moet hebben, een PC dus, en mijn gaming setup staat op een ander verdiep dan mijn PC. Enige praktische bezwaren dus. Moest Apple nu eens een deftige laptop uitbrengen had ik nooit een iMac gekocht. Maar ik wijk af.
Volgende stap: betere kwaliteit. Een beter verhaal vertellen. En misschien eens experimenteren met een camerabeeld van het stuur/de pedalen zelf.
In de reeks “tijden” om te vergelijken binnen 6 maanden:
Gr 2 – Dragon trail Seaside – 1:30:806 (Xanavi Nismo)
Ik ben kandidaat voor de Raad van Bestuur voor Jong VLD Nationaal. In deze blog post vind je de twee redenen waarom ik jouw stem verdien.
Ik heb mij enkel kandidaat gesteld voor de Vlaamse kring, omdat ik tegen de provincies ben. Daar zou ik een heel epistel over kunnen schrijven maar dat ga ik u besparen.
1. Een beter congres – Werken vanuit de inhoud
Ik ben nieuw in de politiek sinds januari 2019. Na een exploratie op lokaal niveau was het me duidelijk dat mijn interesse vooral lag op Federale en Vlaamse onderwerpen.
Ik wil mij verder verdiepen in de thema’s die mij dierbaar zijn: openbaar vervoer, digitalisering, ondernemen, werkgelegenheid, subsidiëring (en de nood daaraan) en fiscaliteit.
Ik wil met kennis van zaken kunnen spreken over belangrijke topics die iedereen aangaan, en werken aan oplossingen om het beter te doen. En ik wil anderen helpen om dat ook te doen.
Ik ben daarom het meest geïnteresseerd in meewerken aan congressen en inhoudelijke debatten. De enige manier om politiek sterk te staan is door kennis van zaken te hebben. Als je niet waarover je spreekt, word je zo onderuit gehaald in een debat.
Eerste tussenkomst in februari 2019 op het jongerencongres.
Mijn 1e reactie na de verkiezingsuitslag
2. Een betere website – Betere online communicatie
Als lid van de Raad van Bestuur van Jong VLD Nationaal wil ik in het bijzonder de online communicatie van Jong VLD verbeteren.
Ik wil zorgen dat mensen die interesse hebben om zich aan te sluiten bij Jong VLD een duidelijk pad hebben om dat te doen.
Momenteel hebben we een redelijke slechte Wix website en ik heb grote plannen om die om te vormen naar iets beters. Vanuit mijn verleden als webdesigner en huidig werk als UI/UX designer kan ik mijn steentje bijdragen.
Ik zoek daarvoor trouwens nog vrijwilligers om iets moois te bouwen.
Waarom RvB Nationaal?
Ik weet dat je geen lid van de Raad van Bestuur moet zijn om een engagement uit te dragen voor Jong VLD.
Maar vanuit het bedrijfsleven weet ik dat het wel helpt om in een positie van beslissingsname te zitten om effectief iets te kunnen doen en uitvoeren.
Daarom wil ik lid zijn van de RvB. Dit om ook te kunnen kiezen voor het juiste kernbestuur.
Samengevat
Samengevat – wil je een betere Jong VLD website? Wil je dat we inhoudelijk sterker staan als partij? Wil je een beter georganiseerd congres? Stem Johan Ronsse.
Ik wil over het algemeen niet teveel zagen over kwaliteit, en al zeker niet te veel kritiek geven op het werk van anderen, maar als ik rond mij kijk is er nog bijzonder veel werk.
Overheidswebsites die niet toegankelijk zijn, terwijl dat wettelijk verplicht is sinds september. Agencies die met werk afkomen dat objectief slechter is dan tien jaar geleden omdat de developers enkel Javascript hebben geleerd op school.
Functionele webapps van bedrijven die opgebouwd zijn met een stevige overheidssteun die 2 dagen down zijn.
Websites die een loopje nemen met je privacy… zelfs de website van het ziekenfonds geeft je zoekopdrachten door aan derden. Hoe kan dit?
Ik blijf elke dag vechten voor kwaliteit, op het web en in software, maar ik zou het waarderen moesten wat meer mensen dat doen.
Ik heb soms het gevoel dat heel wat mensen de fundamenten missen van waar ze nu eigenlijk mee bezig zijn.
There is a difference between JS data objects and JSON, but let’s not go into that for the purposes of this post.
Let’s keep it simple.
Create a new text file. Open 2 square brackets (create an array).
[
]
Start an object:
[
{
}
]
Within the object, set a key and a value.
[
{
"title": "My title"
}
]
Repeat your object if you want multiple entries:
[
{
"title": "My title"
},
{
"title": "My title 2"
}
]
Let’s go back to 1 entry to make this shorter, and let’s add some more properties.
[
{
"title": "My title",
"date": "September 27, 2019",
"content": "My blog post content"
},
]
Now let’s go back to 2 entries to have a logical endpoint to “loop over”.
[
{
"title": "My title",
"date": "September 27, 2019",
"content": "My blog post content"
},
{
"title": "My title 2",
"date": "September 29, 2019",
"content": "My blog post content 2"
},
]
Now you can use this object over in various templating languages or just using plain Javascript.
Here’s an example of a loop with this data object in the Svelte REPL.
