• 1 Post
  • 31 Comments
Joined 10 months ago
cake
Cake day: February 19th, 2024

help-circle




  • bort@sopuli.xyztoMemes@lemmy.mlJust one more lane
    link
    fedilink
    arrow-up
    1
    arrow-down
    2
    ·
    8 months ago

    But only temporarily

    but is it?

    I thought the temporal improvement would be for everyone who already used the high way (because they will get to their destination a little bit faster). And for the few extra people, who start to use the highway but didn’t use it before, the improvment will stay.





  • ============ Top 5: =============== HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor: 97
    AbstractAnnotationConfigDispatcherServletInitializer: 52
    AbstractInterruptibleBatchPreparedStatementSetter: 49
    AbstractInterceptorDrivenBeanDefinitionDecorator: 48
    GenericInterfaceDrivenDependencyInjectionAspect: 47

    ============ Factories: ===============
    DefaultListableBeanFactory$DependencyObjectFactory
    ObjectFactoryCreatingFactoryBean
    SimpleBeanFactoryAwareAspectInstanceFactory
    SingletonBeanFactoryLocator$BeanFactoryGroup
    ConnectionFactoryUtils$ResourceFactory
    DefaultListableBeanFactory$DependencyProviderFactory
    ObjectFactoryCreatingFactoryBean$TargetBeanObjectFactory
    JndiObjectFactoryBean$JndiObjectProxyFactory
    DefaultListableBeanFactory$SerializedBeanFactoryReference
    AbstractEntityManagerFactoryBean$SerializedEntityManagerFactoryBeanReference
    BeanFactoryAspectInstanceFactory
    SingletonBeanFactoryLocator$CountingBeanFactoryReference
    TransactionAwarePersistenceManagerFactoryProxy$PersistenceManagerFactoryInvocationHandler
    AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler

    https://gist.github.com/thom-nic/2c74ed4075569da0f80b


  • the fact that a system eventually becomes complex and flawed is not due to engineering failures - it is inherent in the nature of changing systems

    it is not. It’s just that there will be some point, where you need significant effort to keep the systems structure up to the new demands {1}. I find the debt-metaphor is quite apt [2]: In your scenario the debt accumulates until it’s easier to start fresh. But you can also manage your debt and keep going indefinitily. But in contrast to financial debt, paying of technical debt is much less obvious. First of all it is pretty much impossible to put any kind of exact number on it. On the other hand, it’s very hard to tell what you actually should do to pay it off. (tangent: This is why experienced engineers are worth so much: (among other things) they have seen how debt evolves over time, and may see the early signs).

    [1] https://tidyfirst.substack.com/p/the-openclosedopen-principle

    [2] https://blog.pragmaticengineer.com/tech-debt/




  • I agree, that good cloud engineers can save costs in the cloud. But I also think good non-cloud engineers, can save much much more.

    When you are rewriting your entire stack to leverage cloud performance, you could probably spend a similar effort for a rewrite that increases regular performance by a similar factor.

    RE: Containers, even if you DO go that route…

    I was under the impression, that stateless stuff without containers requires a strong vendor login (aws lambda, google functions, azure function). Are you saying, I could do stateless without vendor-lockin and without containers and without kubernetes? This is news to me. Please point me to some resources