- Company repos are a mess
- Lots of projects, nothing builds, nothing fits in each other
- When using package managers module(a)->uses->module(b) is a prime usecase
- this is slow without tooling
- one way to improve on that is to combine multiple dependants into one repository and manage it with lerna.js
How to balance desire for stable teams with ever-changing biz needs and initiatives?
- Broaden the skillset over the team, so it can handle different kind of tasks (cross disciplinary)
- Be less diverse in docs, architectures and approaches to solve problems. Even Google has only a small amount of languages in production
- Have expectable (aka documented and understood) processes. Where ever you go, you should be able to determine how this are of the team/product works.
- I am not saying: Everyone should do the same form of process management, but the methods should be at least documented and be approachable in the same manner.
- Use pairs with a broad knowledge to get more task types done. Allow for automation of boring
- A software product is part of a service
- Companies already do development in increments
- Moving from Intradisciplinary to Transdisciplinary is natural in modern compaies and personal histories
- Super high quality is possible in software. Although documentation and tooling must be there (in the long term)
- Systems thinking is a theoretical approach to organising teams. The practice of developing working software and other aspects of the service you are working on (Legal, HR, Accounting, Management, Project Management) are practical answers. Don't confuse one with the other.
- Process tailors to the nature of the software you are developing, not the other way around. Software can be very different, from embedded hardware code to one off frontends - It comes with drastically variing lifecycles.
- Overarching moderation
- Voice compression and other Audio tricks with Psychoacoustics
- Advertisement diusguised as Edutainment
- "OpEd"
- Naive Critique
- Overproduction
- Advertisement disguised as Edutainment
The second part of the series covers a in depth inspection of how we structure sourcecode and ship components in the context of a monorepo. There is a big difference between scaffolding with 'polymer init' and having a codebase that is easy to release and still maintainable after a longer time. Having a well organized codebase of components will reduce development drag and lower cost.
The Web Component resides in a es6 Javascript module and describes its dependencies with a npm package.json file. Here we can reference other dependencies that come to us as es6 modules. This is where we have the first little catch 22, since node.js can not yet interpret es6 files with a .js extension and load it via the import keyword without 3rd party tools (babel et al.). This functionality is used only in the browser and polymer build is your tool of choice to bundle all files. There is a polymer lint tool, checking for code style errors, looking a bit more into the specifics of polymer base web components and it
| opensemanticsearch-index-web-crawl https://www.angela-merkel.de/ | |
| opensemanticsearch-index-web-crawl http://www.dietmar-bartsch.de/ | |
| opensemanticsearch-index-web-crawl http://www.von-abercron.de/ | |
| opensemanticsearch-index-web-crawl http://www.doris-achelwilm.de/ | |
| opensemanticsearch-index-web-crawl https://gaggelidis.2017.fdp.de/ | |
| opensemanticsearch-index-web-crawl https://www.abgeordnetenwatch.de/profile/gokay-akbulut | |
| opensemanticsearch-index-web-crawl https://stephan-albani.de/ | |
| opensemanticsearch-index-web-crawl http://www.renata-alt.de/ | |
| opensemanticsearch-index-web-crawl http://www.norbert-altenkamp.de/ | |
| opensemanticsearch-index-web-crawl https://peteraltmaier.de/ |
Over time, more and more workflows get "comoditized" and I want to look at two different projects, one that moves a ecommerce towards a SAAS concept, backed by serverless functions. And another one, moving away from a SAAS provider, to a self built solution - Music Publishing and a audio compression solution with a mechanism to determine the headroom left.
- Management
- Teams
Developing and shipping webcomponents seems simple at first, but modern frontend stacks come with their own set of challenges: A wide set of browsers implements relatively new specs and not everything is set in stone yet and the framework codebases seem to drift, one faster than the other, towards a set of es-x features that allow easy creation and deployment of custom web components with the same architecture. If you set out to create and ship your own set of custom elements this eventualy needs organization and strategies to deploy the code with documentation as easy as possible and continuously while adapting to changes in the underlying frameworks and your own set of features.
In this talk ....