안녕하세요!

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

연락하기

소개

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

역량

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

프로세스 자동화

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

맞춤 시스템

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

미션

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

🚀

기술의 민주화

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

💡

IT와 비즈니스 통합

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

🎯

맞춤 솔루션

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

기술로 비즈니스를 혁신하세요

Dicembre 2024

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

💻 Linguaggi & Tecnologie

☕Java

🐍Python

📜JavaScript

🅰️Angular

⚛️React

🔷TypeScript

🗄️SQL

🐘PHP

🎨CSS/SCSS

🔧Node.js

🐳Docker

🌿Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

연락하기

프로젝트가 있으신가요? 아래 양식을 작성해 주시면 빠르게 답변드리겠습니다.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Flutter 내부 구조: 더 나은 코드 작성을 위한 프레임워크 이해

Flutter는 대부분의 경우에 사용되는 세 개의 병렬 및 동기화 트리를 기반으로 구축되었습니다. 직접적으로는 알지 못하지만 모든 측면을 결정하는 개발자 앱의 성능과 동작. 이해하기 위젯 트리, 는요소 트리 그리고 렌더오브젝트 트리 방식을 변화시키다 Flutter 코드를 작성하는 위치: 이유를 설명하세요. const 그리고 승리의 퍼포먼스, 왜 setState InheritedWidget은 재구축 없이 데이터를 전파하기 때문에 로컬입니다. 쓸모없고 GlobalKey는 위험하기 때문입니다.

이 기사는 이론적인 것이 아닙니다. 각 개념에는 다음과 같은 실제 사례가 함께 제공됩니다. 성능과 아키텍처에 대한 실질적인 영향. 결국 당신은 무엇에 대해 생각할 수있을 것입니다 Flutter가 프레임을 그릴 때 실제로 이런 일이 발생합니다.

무엇을 배울 것인가

세 가지 Flutter 트리: Widget, Element 및 RenderObject
위젯은 불변이고 매 프레임마다 재구성되기 때문입니다.
요소가 수명 주기 및 상태를 관리하는 방법
조정 프로세스: Flutter가 프레임 간의 차이점을 찾는 방법
Perche const 위젯은 요소 트리 재구축을 방지합니다.
처럼 setState 변경되는 하위 트리만 표시합니다.
InheritedWidget: 계단식 재구축 없이 데이터 전파
레이아웃 단계: 제약 조건 감소, 크기 증가, 페인트 중 위치
RepaintBoundary: 다시 그리기 영역을 분리합니다.

세 그루의 설레임나무

Flutter 위젯을 작성하면 UI를 선언적으로 설명하게 됩니다. Flutter는 이 설명을 받아들여 내부적으로 세 가지 별개의 데이터 구조를 구축합니다. 다른 책임을 가지고 있습니다. 이러한 분리는 Flutter 성능의 기초입니다.

나무	가변성	책임	지속
위젯 트리	불변	UI 구성 설명	짧음(빌드마다 다시 빌드됨)
요소 트리	변하기 쉬운	수명주기, 상태, 조정	긴(재구축 간에 지속됨)
렌더오브젝트 트리	변하기 쉬운	레이아웃, 적중 테스트, 페인팅	긴(느리게 업데이트됨)

위젯 트리: 불변 설명

Flutter의 위젯과 변경할 수 없는 구성: 방법을 설명합니다. UI의 일부가 나타나야 하지만 상태나 렌더링이 포함되어 있지 않습니다. 전화할 때마다 build(), Flutter는 새로운 Widget 객체를 생성합니다 — 위젯은 단순히 구성 개체에 할당되므로 경제적입니다. 힙에 즉시 가비지 수집 후보가 됩니다.

# Dimostrazione: Widget = configurazione immutabile

// Questo codice crea nuovi oggetti Widget ogni frame di build:
class CounterWidget extends StatefulWidget {
  @override
  State<CounterWidget> createState() => _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
  int _count = 0;

  @override
  Widget build(BuildContext context) {
    // build() restituisce un NUOVO oggetto Text ogni volta che viene chiamato
    // Ma Flutter NON ricrea il RenderObject corrispondente ogni volta
    // Controlla invece se la configurazione e "uguale" tramite il type + key
    return Column(
      children: [
        // NUOVO oggetto Text creato ogni build, ma efficiente:
        Text('Count: $_count'),  // runtimeType: Text
        ElevatedButton(
          onPressed: () => setState(() => _count++),
          child: const Text('Increment'),  // const: NON ricrea il Widget
        ),
      ],
    );
  }
}

// const Text('Increment') e allocato UNA SOLA VOLTA in memoria
// come costante compile-time. Ogni rebuild del parent usa lo stesso oggetto.
// Questo e il motivo per cui flutter lint raccomanda sempre const.

요소 트리: Lifecycle Manager

Element 트리는 Flutter 프레임워크의 핵심입니다. 요소 트리의 각 노드 트리의 위젯과 일치하지만 재빌드 후에도 유지됩니다. 요소는 알고 있다 현재 위젯을 사용하여 상태를 관리하고(StatefulElement를 통해) 결정합니다. RenderObject를 업데이트할지 아니면 새 개체를 생성할지 여부입니다.

# Il processo di reconciliation (diffing) di Flutter

// Scenario: aggiorno il type di un widget in una lista
// PRIMA del rebuild:
Column(
  children: [
    Text('Hello'),        // Element: TextElement
    Icon(Icons.star),     // Element: LeafRenderObjectElement
  ],
)

// DOPO il rebuild:
Column(
  children: [
    Text('Hello'),        // stesso type -> Flutter RIUSA l'Element
    ElevatedButton(       // type diverso -> Flutter DISTRUGGE vecchio Element
      onPressed: () {},   //                e CREA nuovo Element (e RenderObject)
      child: const Text('OK'),
    ),
  ],
)

// La regola: Flutter fa il match degli Element per POSIZIONE e TIPO (+ Key se presente)
// Se type corrisponde: aggiorna la configurazione dell'Element esistente
// Se type non corrisponde: distrugge il vecchio Element e crea tutto da zero

// IMPLICAZIONE: le liste dinamiche DEVONO usare Key
// SENZA Key (SBAGLIATO):
ListView.builder(
  itemBuilder: (context, index) => ListTile(
    title: Text(items[index].name),  // no key!
  ),
)
// Se riordini la lista, Flutter puo assegnare lo stato sbagliato agli item

// CON Key (CORRETTO):
ListView.builder(
  itemBuilder: (context, index) => ListTile(
    key: ValueKey(items[index].id),  // chiave unica e stabile
    title: Text(items[index].name),
  ),
)

StatefulWidget: 국가가 사는 곳

새로운 Flutter 개발자들이 가장 자주 묻는 질문 중 하나는 "왜 상태가 위젯을 다시 빌드하면 손실되지 않나요?" 대답은 요소 트리에 있습니다. 상태는 요소(특히 StatefulElement), 아니 위젯에서.

# Perche lo stato persiste tra rebuild

// StatefulWidget: Widget (immutabile) + State (mutabile)
class MyWidget extends StatefulWidget {
  const MyWidget({super.key, required this.title});
  final String title;  // configurazione immutabile

  @override
  State<MyWidget> createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  // LO STATO VIVE QUI, nell'oggetto State
  // L'Element tiene un riferimento a questo State
  int _counter = 0;

  @override
  Widget build(BuildContext context) {
    // Il Widget (MyWidget) viene ricreato, ma _MyWidgetState persiste
    // L'Element aggiorna il suo _widget (la nuova configurazione)
    // ma mantiene il suo _state (il vecchio State)
    return Text('${widget.title}: $_counter');
    // widget.title viene aggiornato automaticamente dall'Element
    // quando il parent ricostruisce con un nuovo title
  }
}

// Lifecycle completo di StatefulElement:
// 1. Element.mount()     -> State.initState()
// 2. Element.update()    -> State.didUpdateWidget() (se widget parent ricostruisce)
// 3. Element.deactivate() -> State.deactivate() (rimosso temporaneamente dal tree)
// 4. Element.unmount()   -> State.dispose()        (rimosso definitivamente)

// IMPORTANTE: dispose() DEVE liberare tutte le risorse
// (AnimationController, StreamSubscription, TextEditingController, etc.)
@override
void dispose() {
  _controller.dispose();     // AnimationController
  _subscription.cancel();    // StreamSubscription
  _textController.dispose(); // TextEditingController
  super.dispose();
}

RenderObject 트리: 레이아웃 및 페인팅

RenderObject 트리는 금속에 가장 가까운 수준입니다. 레이아웃을 관리합니다. (위치 및 크기 계산), 적중 테스트(어떤 위젯이 터치에 반응하는지) 및 페인팅(캔버스에 그리기). Element 트리와 비교하여 RenderObject 트리는 필요한 경우에만 업데이트되며 업데이트는 증분식입니다.

# Il Layout pass: constraints down, sizes up, positions during paint

// Flutter usa un sistema di constraint-based layout:
// 1. Il parent passa CONSTRAINTS al child (max/min width/height)
// 2. Il child calcola la sua SIZE all'interno dei constraints
// 3. Il parent posiziona il child durante il paint

// Esempio: come Column calcola il layout
Column(
  children: [
    // 1. Column passa: BoxConstraints(maxWidth: 390, maxHeight: infinity)
    Text('Hello'),
    // Text risponde: "ho bisogno di 40px height"
    // 2. Column passa constraints rimanenti al secondo child
    Expanded(
      // Expanded usa TUTTA l'altezza rimanente
      child: ListView(...),
    ),
  ],
)

// RepaintBoundary: isola una zona dal ciclo di repaint
// Usalo per widget che si aggiornano spesso e non devono
// far ridisegnare il resto della UI
RepaintBoundary(
  child: AnimatedProgressBar(progress: _progress),
)

// Senza RepaintBoundary: ogni frame del progressbar ridisegna tutta la pagina
// Con RepaintBoundary: solo il progressbar viene ridisegnato ogni frame

// CustomPainter con shouldRepaint ottimizzato:
class ChartPainter extends CustomPainter {
  const ChartPainter({required this.data, required this.color});
  final List<double> data;
  final Color color;

  @override
  void paint(Canvas canvas, Size size) {
    // ... codice di disegno
  }

  @override
  bool shouldRepaint(ChartPainter oldDelegate) {
    // Ridisegna SOLO se i dati o il colore sono cambiati
    // Confronto reference per le liste (usa listEquals per confronto profondo)
    return oldDelegate.data != data || oldDelegate.color != color;
  }
}

const 위젯: 오해된 성능 승리

키워드 const 위젯에서의 선택은 단지 스타일적 선호가 아닙니다. 요소 트리에서 조정 작업을 제거하는 근본적인 최적화입니다.

# const: perche e una performance win concreta

// SENZA const: ogni build() del parent crea nuovi oggetti
class ParentWidget extends StatefulWidget {
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        // NUOVO oggetto Text creato ogni rebuild del parent
        // Flutter deve fare il confronto nell'Element tree
        Text('Static label'),
        // widget che cambia davvero
        Text('Dynamic: $_counter'),
      ],
    );
  }
}

// CON const: Flutter usa lo stesso oggetto compile-time
class ParentWidget extends StatefulWidget {
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        // Stesso oggetto compile-time, NESSUN confronto nell'Element tree
        const Text('Static label'),
        // Solo questo widget causa lavoro all'Element tree
        Text('Dynamic: $_counter'),
      ],
    );
  }
}

// La regola: const rende il Widget una "costante compile-time"
// L'Element tree vede che il Widget e identico (stesso riferimento in memoria)
// e salta completamente la fase di reconciliation per quel sottoalbero

// flutter lint: "prefer_const_constructors" ti dice dove aggiungere const
// flutter analyze conta quante opportunita stai perdendo

InheritedWidget: 효율적인 데이터 전파

InheritedWidget은 Flutter가 데이터를 트리 아래로 전파하는 메커니즘입니다. 각 레이어를 통해 매개변수를 전달할 필요 없이 그리고 Theme의 기본이 되는 MediaQuery, 네비게이터와 리버포드 자체.

# InheritedWidget: come funziona internamente

// Implementazione manuale (come funziona Theme, MediaQuery, etc.)
class AppConfig extends InheritedWidget {
  const AppConfig({
    super.key,
    required this.apiBaseUrl,
    required this.isDarkMode,
    required super.child,
  });

  final String apiBaseUrl;
  final bool isDarkMode;

  // Metodo statico per accedere dal tree discendente
  static AppConfig of(BuildContext context) {
    final config = context.dependOnInheritedWidgetOfExactType<AppConfig>();
    assert(config != null, 'AppConfig non trovato nel tree');
    return config!;
  }

  // CRITICO: updateShouldNotify decide quali widget discendenti si ricostruiscono
  // Restituisci TRUE solo se il dato e davvero cambiato
  @override
  bool updateShouldNotify(AppConfig oldWidget) {
    return apiBaseUrl != oldWidget.apiBaseUrl ||
           isDarkMode != oldWidget.isDarkMode;
  }
}

// Utilizzo: qualsiasi widget discendente puo accedere ad AppConfig
class SomeDeepWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // context.dependOnInheritedWidgetOfExactType registra questo widget
    // come "dipendente" da AppConfig: si ricostruira quando AppConfig cambia
    final config = AppConfig.of(context);

    return Text(config.isDarkMode ? 'Dark Mode' : 'Light Mode');
  }
}

// DIFFERENZA IMPORTANTE:
// context.dependOnInheritedWidgetOfExactType -> si iscrive agli update (rebuild)
// context.getInheritedWidgetOfExactType      -> legge senza iscriversi (no rebuild)

// Questa distinzione e il motivo per cui:
// Theme.of(context)       -> causa rebuild quando il tema cambia
// Theme.of(context).colors -> stesso effetto, non filtra per sub-proprieta

setState: 로컬 범위 및 효율적인 이유

# setState: marca solo il sottoalbero necessario

// setState non "ricostruisce tutta l'app" - marca solo l'Element di QUESTO State
// come "dirty" nella lista dei widget da rebuildarsi nel prossimo frame

class CounterPage extends StatefulWidget {
  @override
  State<CounterPage> createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int _count = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      // AppBar non dipende da _count -> NON si ricostruisce
      appBar: const AppBar(title: Text('Counter')),
      body: Center(
        // SOLO questo Text si ricostruisce (il suo Element viene marcato dirty)
        child: Text('$_count'),
      ),
      floatingActionButton: FloatingActionButton(
        // La FAB non dipende da _count -> NON si ricostruisce
        onPressed: () => setState(() => _count++),
        child: const Icon(Icons.add),
      ),
    );
  }
}

// Per ridurre ulteriormente il scope del rebuild: estrai il widget che cambia
// in un StatefulWidget separato con il suo setState locale

// ANTI-PATTERN: setState al livello piu alto per dati condivisi
// SOLUZIONE: Riverpod, InheritedWidget o altri state management
// che permettono rebuild granulari solo ai widget che usano quel dato

키: 유형 및 사용 시기 안내

# Keys: ValueKey, ObjectKey, UniqueKey, GlobalKey

// ValueKey: key basata su un valore primitivo (id, stringa)
// USO: liste ordinate/filtrate dove gli item possono spostarsi
ListView.builder(
  itemBuilder: (context, index) => ProductCard(
    key: ValueKey(products[index].id), // usa l'id del dominio, stabile
    product: products[index],
  ),
)

// ObjectKey: key basata su un oggetto (confronto per identita)
// USO: quando hai un oggetto come chiave unica
ValueKey(product.id)       // preferibile: confronta l'ID (stringa/int)
ObjectKey(product)          // confronta il riferimento all'oggetto

// UniqueKey: genera una key unica ogni volta (non stabile tra rebuild!)
// USO: forzare la ricostruzione di un widget (reset del suo stato)
UniqueKey() // ATTENZIONE: ogni rebuild crea una key diversa = State perso

// GlobalKey: accede allo State o al RenderObject da fuori del tree
// RARO: evita quando possibile, ha overhead significativo
final _formKey = GlobalKey<FormState>();
Form(
  key: _formKey,
  child: Column(children: [...]),
)
// Poi: _formKey.currentState!.validate()

// REGOLA: usa GlobalKey solo per Form, ScaffoldMessenger, Navigator
// Per tutto il resto: passa callbacks o usa state management

성능 체크리스트: Flutter 내부 실습

const 가능하다면: 모든 위젯은 정적이어야 합니다 const. 린트 규칙 활성화 prefer_const_constructors.
동적 목록의 핵심: 어느 ListView.builder o Column 역동적인 아이들과 함께 사용해야 합니다 ValueKey 도메인 ID를 기반으로 합니다.
가장 낮은 수준의 setState: 별도의 StatefulWidget으로 추출 루트 수준에서 setState를 호출하는 대신 변경되는 UI 부분입니다.
애니메이션용 RepaintBoundary: 연속 애니메이션 래핑 (로드 스피너, 진행률 표시줄, 카운트다운) RepaintBoundary.
CustomPainter에서 다시 그려야 합니다: 항상 논리를 구현 항상 반환하는 대신 정확함 true.
불필요한 글로벌키 없음: 각 GlobalKey에는 오버헤드가 있습니다. 그것을 사용 꼭 필요한 경우에만(Form, Scaffold, Navigator)

결론

Flutter의 세 가지 트리(Widget, Element, RenderObject) 이해하기 "모호한 모범 사례"부터 인과적 이해까지 모든 코드 결정: 아시다시피 정확히 왜 const 그것은 효과가 있다. 왜냐면 setState 전자 InheritedWidget은 불필요한 계단식 재구축을 일으키지 않기 때문에 효율적입니다.

이러한 내부 지식은 학술적인 세부 사항이 아닙니다. 60fps로 앱을 만드는 사람으로부터 "일을 잘하게 만드는" Flutter 개발자 성능을 유지하는 보장되고 예측 가능한 메모리 공간 및 아키텍처 코드베이스가 성장함에 따라. 프레임워크는 정확한 아키텍처 선택을 수행했습니다. — 이를 이해한다는 것은 프레임워크에 반대하는 대신 프레임워크와 협력할 수 있다는 것을 의미합니다.