poniedziałek, 22 września 2025

dev{properties} - FOMO w IT – jak uczyć się nowych technologii bez stresu

Rynek IT bombarduje nas nowościami: co tydzień nowy framework, narzędzie DevOps, biblioteka AI. Nic dziwnego, że wielu specjalistów ma FOMO – fear of missing out. Ale pogoń za wszystkim kończy się wypaleniem, a nie ekspertyzą.



Dlaczego FOMO w IT jest groźne?

  • Rozproszenie uwagi – uczysz się 10 rzeczy naraz i żadnej nie opanowujesz głębiej.
  • Brak satysfakcji – zawsze wydaje się, że „inni wiedzą więcej”.
  • Pułapka porównań – social media developerów kreują obraz „wszyscy już to znają”, co nie jest prawdą.

Jak uczyć się bez FOMO?

  1. Zdefiniuj kierunek: wybierz domenę (np. FinTech, e-commerce, AI/ML) i ucz się tego, co ją realnie wspiera.
  2. Planuj cykle: np. kwartalny „focus skill” – jedna nowa technologia, jeden projekt praktyczny, jedno podsumowanie.
  3. Filtruj nowości: zanim coś dodasz do listy „must learn”, zapytaj: czy to przybliża mnie do mojej ścieżki?
  4. Głębia > szerokość: lepiej być ekspertem w 2-3 obszarach niż „turystą” w 20 frameworkach.
  5. Akceptuj nie-wiedzę: w IT zawsze będzie coś, czego nie znasz – i to jest normalne.

Praktyczny tip: Notion / Obsidian „Learning Backlog”

Zamiast rzucać się na wszystko od razu – notuj nowinki w backlogu wiedzy. Co kwartał robisz przegląd i wybierasz tylko kilka rzeczy, które mają sens w Twojej ścieżce. Reszta? Bez żalu zostaje na liście „kiedyś”. To redukuje stres i daje poczucie kontroli.


Masz swoje sposoby na radzenie sobie z FOMO w IT? Napisz w komentarzu lub podziel się na LinkedIn – chętnie zbiorę najlepsze praktyki od społeczności i zrobię z nich kolejny wpis.

środa, 17 września 2025

dev{properties} - Rynek IT 2025 – jakie kompetencje są dziś w cenie?

W dyskusji o przyszłości pracy w IT coraz częściej powraca wniosek: firmy nie szukają już wyłącznie „klepaczy kodu”. Oczekują inżynierów, którzy rozumieją kontekst, potrafią zadać właściwe pytania „po co?” i dowozić wartość biznesową – we współpracy z klientem i produktem, a nie obok nich. To przesunięcie akcentów widać w relacjach z najnowszych debat branżowych i podsumowaniach rynku pracy. 



Era bezrefleksyjnego „klepania kodu” dobiegła końca. Organizacje szukają partnerów, którzy myślą krytycznie, rozumieją biznes i nie boją się kwestionować założeń. :contentReference

Co dziś jest w cenie?

  • Myślenie produktowo-biznesowe – inżynier pyta „dla kogo i dlaczego?”, a nie tylko „jak to napisać?”. :contentReference
  • Kompetencje miękkie – komunikacja, współpraca, umiejętność słuchania i klarownego wyrażania myśli. :contentReference
  • Fundament technologiczny – AI przyspiesza pracę, ale nie zastępuje rozumienia algorytmów i architektury. :contentReference
  • Specjalizacja domenowa (FinTech, MedTech, retail) – łączenie wiedzy technicznej z branżową buduje przewagę. :contentReference
  • Nastawienie na naukę – „life-long learning” bez FOMO, z intencją i planem rozwoju. 

AI zmienia zasady gry (ale nie zwalnia z myślenia)

Narzędzia AI demokratyzują wytwarzanie oprogramowania, jednak podnoszą poprzeczkę: zespół musi precyzyjnie definiować cele, rozumieć trade-offy i dbać o jakość. „Mówienie do komputera” to nie strategia – to interfejs. Strategią pozostaje architektura, model domeny i odpowiedzialność za efekt. :contentReference

Różne pokolenia – różne atuty

Starsi specjaliści często wygrywają szerszym kontekstem i stabilnością decyzyjną, młodszym z kolei brakuje nieraz cierpliwości i obycia złożonymi strukturami organizacji. Kluczem jest wymiana wiedzy międzypokoleniowej i świadome kształcenie liderów – „inkubacja” managementu zamiast przypadkowych awansów. 

Co robić teraz? – checklista dla Ciebie

  1. Zdefiniuj swoją tezę zawodową: jaka domena, jaki rodzaj problemów, jaki typ organizacji (produkt, consulting, R&D)? 
  2. Buduj kapitał domenowy: czytasz raporty branżowe, rozumiesz regulacje, potrafisz rozrysować procesy w BPMN/UML?
  3. Trenuj krytyczne myślenie: przy każdym tasku odpowiedz na „dla kogo”, „jaki efekt biznesowy”, „jak to zweryfikujemy”.
  4. AI jako copilot: prompts → testy → metryki jakości. Zawsze rozumiesz, co robi każda linijka wygenerowanego kodu. 
  5. Komunikacja: klarowne PR-y, ADR-y (Architecture Decision Records), zwięzłe RFC i dema dla biznesu.

Co robić teraz? – checklista dla firm

  1. Projektuj środowisko bezpiecznej porażki: promuj eksperymenty, nie karz za błędy; dbaj o higienę pracy i urlopy. 
  2. Inwestuj w liderów: programy rozwoju managementu, coaching feedbacku, kultura uczenia się (zamiast „szef kazał na szkolenie”). 
  3. Rekrutacja na myślenie: ocena rozumowania, decyzji i empatii – dopiero potem stos narzędzi.
  4. Stawiaj na produktowość: mniej outsourcingu „tasków”, więcej własności domeny i produktu. 

Polska: od centrum usług do centrum innowacji?

Polska pozostaje silnym hubem outsourcingowym w Europie i to realny wkład do PKB. Ale jeśli chcemy zatrzymać wiedzę i zwiększyć marżowość, kierunek jest jasny: tworzenie własnych produktów i IP zamiast montowni cudzych rozwiązań. 


Na podstawie debaty i materiałów prasowych podsumowujących zmiany na rynku IT (Business Insider, 13 września 2025). 

poniedziałek, 8 września 2025

AI w pracy programistów: rośnie użycie, maleje zaufanie

Według najnowszych badań deweloperzy coraz częściej korzystają z narzędzi AI, ale jednocześnie podchodzą do nich z coraz większym dystansem. To ciekawe zjawisko – rosnąca adopcja idzie w parze ze spadającym zaufaniem.



Więcej AI w codziennej pracy

Jeszcze dwa lata temu AI w świecie programistów było traktowane raczej jako ciekawostka. Dziś narzędzia takie jak GitHub Copilot, ChatGPT czy Claude są na stałe obecne w warsztacie wielu deweloperów. Badanie pokazuje, że ponad 70% programistów regularnie używa AI w swojej pracy – od generowania kodu, przez testy, aż po dokumentację.

Mniej wiary w wyniki

Jednocześnie rośnie świadomość ograniczeń AI. Coraz więcej programistów zauważa, że modele potrafią się mylić, „halucynować” odpowiedzi lub generować kod, który wygląda poprawnie, ale w rzeczywistości zawiera błędy. Efekt? Spada zaufanie do wyników AI – tylko niewielka grupa deweloperów ufa bezkrytycznie generowanemu kodowi.

Dlaczego tak się dzieje?

  • Doświadczenie – im dłużej pracujemy z AI, tym lepiej rozumiemy jej mocne i słabe strony.
  • Ryzyko jakości – błędy w kodzie mogą prowadzić do kosztownych problemów, dlatego każdy fragment wygenerowany przez AI wymaga weryfikacji.
  • Edukacja – społeczność programistów coraz częściej dzieli się przykładami „AI failów”, co zwiększa świadomość zagrożeń.

AI jako narzędzie, nie zastępstwo

Wnioski są dość jasne: AI nie zastąpi programistów, ale staje się dla nich ważnym wsparciem. Zaufanie do AI może maleć, ale jednocześnie rośnie umiejętność krytycznego korzystania z tych narzędzi. To znak dojrzałości całej branży.

Co dalej?

Można się spodziewać, że AI pozostanie nieodłącznym elementem procesu wytwarzania oprogramowania – ale bardziej jako „inteligentny asystent”, niż pełnoprawny deweloper. Kluczowa będzie umiejętność oceny jakości wygenerowanego kodu i świadomego korzystania z AI w projektach.


Źródło inspiracji: ainativedev.io

poniedziałek, 1 września 2025

Agent AI w Javie: Spring AI + Docker Compose (krok po kroku)

Czy wiesz że w mniej niż godzinę zbudujesz i uruchomisz agenta AI? Agenta opartego o Spring AI, z wystawionym endpointem HTTP, gotowym do konteneryzacji i docker compose up. Pokażę Ci jak podłączyć narzędzia (Tools) w dwóch wariantach: własne metody oznaczone @Tool oraz serwer MCP (np. Brave/DuckDuckGo) w Compose.



Co zbudujemy

Wymagania

  • Java 21, Maven
  • Docker + Docker Compose
  • (Opcjonalnie) Klucz API do dostawcy modelu (np. OpenAI) – trzymamy w sekrecie

1) Inicjalizacja projektu

Najprościej zacząć od Spring Initializr – wybierz Spring Boot 3.4+, dodaj „Web” oraz startery Spring AI. Ręcznie w pom.xml możesz dodać:

<dependencies>
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-openai</artifactId>
    <version>1.0.1</version>
  </dependency>

  <!-- MCP klient, żeby podpiąć zewnętrzne serwery narzędzi (np. Brave/DuckDuckGo) -->
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-client</artifactId>
    <version>1.0.1</version>
  </dependency>

  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
</dependencies>

Konfiguracja minimalna w src/main/resources/application.yml:

spring:
  ai:
    openai:
      api-key: ${OPENAI_API_KEY:} # NIE trzymaj klucza w repo; wstrzykniemy go z Dockera
      chat:
        options:
          # Możesz wskazać model, np.:
          # model: gpt-4o-mini
          # temperature: 0.2

# (Opcjonalnie) MCP – rejestrujemy serwer zewnętrznych narzędzi
  # ai:
  #   mcp:
  #     clients:
  #       search:
  #         transport: http-sse
  #         endpoint: http://mcp-brave:8080/  # nazwa usługi z Compose
  #         auto-initialize: true

2) Minimalny agent: ChatClient + @Tool

Spring AI pozwala wystawić metody jako tools, po które może sięgnąć model w trakcie rozmowy (Function/Tool Calling). Na start zróbmy prosty tool zwracający „plan dnia” na podstawie promptu.

package dev.softwareveteran.agent;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.tool.annotation.Tool;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.*;

record ChatRequest(String message) {}
record ChatResponse(String content) {}

@Component
class PlanningTools {

  @Tool(name = "plan_day", description = "Tworzy krótki plan dnia na podstawie preferencji użytkownika.")
  public String planDay(String preferences) {
    // Tu mógłbyś podpiąć swoje API/kalendarz. Na razie demo.
    return """
      - 08:00 poranna kawa ☕
      - 09:00 deep work nad najważniejszym zadaniem
      - 12:30 szybki lunch
      - 14:00 spotkania
      - 17:30 sport/relaks
    """;
  }
}

@RestController
@RequestMapping("/chat")
class ChatController {

  private final ChatClient chat;

  ChatController(ChatClient.Builder builder, PlanningTools tools) {
    this.chat = builder
      .defaultSystem("Jesteś pomocnym asystentem architekta oprogramowania. " +
                     "Jeśli użytkownik pyta o plan dnia, skorzystaj z narzędzia 'plan_day'.")
      .tools(tools)   // <- .build="" chat="" chatrequest="" chatresponse="" code="" content="" equestbody="" new="" ool="" ostmapping="" public="" rejestrujemy="" req="" return="" var="">

Test lokalny:

./mvnw spring-boot:run
curl -X POST http://localhost:8080/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"Zaproponuj plan dnia dla pracy koncepcyjnej i sportu wieczorem"}'

3) (Opcjonalnie) Narzędzia przez MCP (np. web search)

Gdy potrzebujesz „prawdziwych” akcji – wyszukiwania w sieci, plików, pogody – nie musisz wszystkiego programować sam. MCP (Model Context Protocol) udostępnia gotowe serwery narzędzi, które Twój agent może wywoływać jak zwykłe tools. Wystarczy dodać starter klienta MCP i wskazać endpoint MCP w konfiguracji (sekcja powyżej), a następnie dorzucić poradnikowo prosty advisor w budowie klienta (Spring AI zrobi większość za Ciebie). W Compose dołożymy kontener z serwerem MCP, np. Brave Search lub DuckDuckGo.

4) Dockerfile – produkcyjny build Javy

# --- build stage ---
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -q -DskipTests dependency:go-offline
COPY src ./src
RUN mvn -q -DskipTests package

# --- runtime stage ---
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
# Zadbaj o sensowne limity pamięci w runtime:
ENV JAVA_TOOL_OPTIONS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=75"
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/app.jar"]

5) Docker Compose – jeden plik, cały stos

Przykładowy compose.yaml uruchamia aplikację oraz (opcjonalnie) serwer MCP Brave Search. Klucz API do modelu przekazujemy jako secret – bezpiecznie i poza obrazem.

name: spring-ai-agent

services:
  app:
    build: .
    image: swv/spring-ai-agent:latest
    ports:
      - "8080:8080"
    environment:
      # Spring AI pobierze klucz z env – nie wklejaj go do application.yml
      OPENAI_API_KEY_FILE: /run/secrets/openai_api_key
      # Jeśli korzystasz z MCP (sekcja application.yml):
      # SPRING_AI_MCP_CLIENTS_SEARCH_ENDPOINT: http://mcp-brave:8080/
    secrets:
      - openai_api_key
    depends_on:
      - mcp-brave
    # Opcjonalnie healthcheck
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8080/actuator/health"]
      interval: 15s
      timeout: 3s
      retries: 10

  # (opcjonalnie) Serwer MCP Brave Search – wymaga BRAVE_API_KEY
  mcp-brave:
    image: shoofio/brave-search-mcp-sse:latest
    environment:
      BRAVE_API_KEY_FILE: /run/secrets/brave_api_key
      PORT: "8080"
    ports:
      - "18080:8080"
    secrets:
      - brave_api_key

secrets:
  openai_api_key:
    file: ./secret.openai-api-key
  brave_api_key:
    file: ./secret.brave-api-key

Uruchomienie:

# 1) Zapisz sekrety do plików (po jednym w linii)
echo "sk-...twoj-openai-key..." > secret.openai-api-key
echo "brv-...twoj-brave-key..." > secret.brave-api-key

# 2) Odpal całość
docker compose up --build

# 3) Test
curl -X POST http://localhost:8080/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"Znajdź najnowsze wieści o Spring AI i zrób 3-punktowe streszczenie"}'

Uwaga: jeśli nie chcesz MCP – usuń usługę mcp-brave i odpowiadające jej zmienne. Zamiast OpenAI możesz podłączyć lokalny model przez Docker Model Runner/Ollama – wtedy w konfiguracji Spring AI wybierz odpowiedniego providera i endpoint.

Co dalej?

  • Dodaj pamięć rozmowy i RAG (Vector Store) – Spring AI ma gotowe adaptery.
  • Dołóż drugi/zewnętrzny tool (np. pogodę/finanse) i pozwól modelowi decydować, którego użyć.
  • Wydziel agenta do osobnego mikroserwisu; dziel się nim przez HTTP/GRPC.

Przydatne linki