Emmapedia - User contributions [en]

Emmapedia

2026-08-31T20:08:21Z

Emma72718:

= There is no such thing as Emmapedia =

== But, this is how I work: ==

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

== Then: ==
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And if it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.
* Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, '''''DO SPEAK UP'''''. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on.
* Do not trust whatever your AI agent tells you. If something is off, ask for details about it. Ask for sources, and check those, don't get caught up in an AI induced [https://en.wikipedia.org/wiki/Gish_gallopgish%20gallop gish gallop]. I have seen ChatGPT answers with sources and annotations that were entirely made up.
* Vibe coding isn't inherently bad. Vibe coding without a plan is. Before pitching an application idea to your favourite agent, decide for yourself what the software should do and what it should not do. Make a list of acceptance criteria, and tell the agent to first create a plan and divide it in epics and stories, just like you would do with a classic software project.
* Get the right plugins and skills for your agent. Software architecture, UX design, cloud infra, documentation retrieval and documentation creation: use them.
* Sometimes you need to create your own skill. There are skill creation skills and plugins, check them out. Skill building rule 1: explicitly forbid the agent to update the skill. Rule 2: tell the agent to add new insights to a secondary file, that never should be used as a source of information. Then, you can periodically separate valuable skill insights from opinionated one-offs and authorise the agent to move the valuabe bits into your skill.
* Cloud providers have all kinds of solutions for all kinds of problems. Databases, queues, storage, VMs, event loggers, function apps, container clusters, 20 ways to serve web sites. I'm kind of convinced that we're slowly moving to everything containerised, so that clusters like Kubernetes can be moved more or less freely between cloud providers, or to have services spread across providers. If you have continuity requirements like NIS2 you cannot put all your eggs in one basket, or have plans ready to move your eggs into another basket within hours.

== You already knew that? ==

Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long, or if 'halfway' proves to be all there is.)

Emmapedia

2026-08-31T20:00:19Z

Emma72718:

= There is no such thing as Emmapedia =

== But, this is how I work: ==

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

== Then: ==
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And if it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.
* Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, '''''DO SPEAK UP'''''. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on.
* Do not trust whatever your AI agent tells you. If something is off, ask for details about it. Ask for sources, and check those, don't get caught up in an AI induced [https://en.wikipedia.org/wiki/Gish_gallopgish%20gallop gish gallop]. I have seen ChatGPT answers with sources and annotations that were entirely made up.
* Vibe coding isn't inherently bad. Vibe coding without a plan is. Before pitching an application idea to your favourite agent, decide for yourself what the software should do and what it should not do. Make a list of acceptance criteria, and tell the agent to first create a plan and divide it in epics and stories, just like you would do with a classic software project.
* Get the right plugins and skills for your agent. Software architecture, UX design, cloud infra, documentation retrieval and documentation creation: use them.
* Sometimes you need to create your own skill. There are skill creation skills and plugins, check them out. Skill building rule 1: explicitly forbid the agent to update the skill. Rule 2: tell the agent to add new insights to a secondary file, that never should be used as a source of information. Then, you can periodically separate valuable skill insights from opinionated one-offs and authorise the agent to move the valuabe bits into your skill.

== You already knew that? ==

Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long, or if 'halfway' proves to be all there is.)

Emmapedia

2023-01-25T13:09:08Z

Emma72718:

Emmapedia

2023-01-25T13:08:28Z

Emma72718:

Emmapedia

2023-01-16T07:41:07Z

Emma72718:

Emmapedia:Privacy policy

2023-01-16T07:20:01Z

Emma72718: Created page with "I'm not collecting anything. Oh wait, your IP address might be in the server logs. But I'm not doing anything with that log and it will rotate after a while. All your secrets are safe on this site because you're not able to tell them here anyway. There might be technical cookies somewhere but no tracking is done, so the site doesn't even need the infamous EU cookie wall."

I'm not collecting anything. Oh wait, your IP address might be in the server logs. But I'm not doing anything with that log and it will rotate after a while. All your secrets are safe on this site because you're not able to tell them here anyway. There might be technical cookies somewhere but no tracking is done, so the site doesn't even need the infamous EU cookie wall.

Emmapedia:General disclaimer

2023-01-16T07:16:29Z

Emma72718: Created page with "I'm not claiming anything here."

I'm not claiming anything here.

Emmapedia:About

2023-01-16T07:14:59Z

Emma72718: Created page with "= Emma Laurijssens van Engelenhoven = ; LinkedIn: : https://www.linkedin.com/in/emmalaurijssens ; Mastodon: : https://mstdn.esp.nl/@elaurijssens ; Address, phone and e-mail: : Sorry, that would be too easy for the bots. Send me a message on Mastodon or LinkedIn."

= Emma Laurijssens van Engelenhoven =

; LinkedIn:
: https://www.linkedin.com/in/emmalaurijssens

; Mastodon:
: https://mstdn.esp.nl/@elaurijssens

; Address, phone and e-mail:
: Sorry, that would be too easy for the bots. Send me a message on Mastodon or LinkedIn.

Emmapedia

2023-01-16T06:52:31Z

Emma72718:

Emmapedia

2023-01-16T06:35:19Z

Emma72718:

Emmapedia

2023-01-16T06:33:38Z

Emma72718:

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.

Emmapedia

2023-01-16T06:20:39Z

Emma72718:

Emmapedia

2023-01-16T06:19:54Z

Emma72718:

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2023-01-13T13:59:10Z

Emma72718: /* There is no such thing as Emmapedia */

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2023-01-13T13:31:26Z

Emma72718: /* There is no such thing as Emmapedia */

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2023-01-13T13:21:42Z

Emma72718: /* There is no such thing as Emmapedia */

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2022-08-25T07:05:26Z

Emma72718: Created page with "= There is no such thing as Emmapedia = Try to figure it out for yourself. Useful links: * [https://google.com Google] * [https://stackoverflow.com Stackoverflow] * [https://serverfault.com Serverfault]"

= There is no such thing as Emmapedia =

Try to figure it out for yourself.

Useful links:

* [https://google.com Google]
* [https://stackoverflow.com Stackoverflow]
* [https://serverfault.com Serverfault]

MediaWiki:Mainpage-nstab

2022-08-25T07:04:22Z

Emma72718: Created page with "Emmapedia"

Emmapedia

MediaWiki:Mainpage-description

2022-08-25T07:03:56Z

Emma72718: Created page with "Emmapedia"

Emmapedia

MediaWiki:Mainpage

2022-08-25T07:03:31Z

Emma72718: Created page with "Emmapedia"

Emmapedia