Sanayi ve Teknoloji Bakanı Mehmet Fatih Kacır, otomotiv sektörü hakkında açıklamalarda bulundu

Bakan Kacır, otomotiv sektörü hakkında açıklamalarda bulundu

Bakan Kacır, otomotiv sektörü hakkında açıklamalarda bulunduİstanbul Sanayi Odası’nda gerçekleştirilen Otomotiv Sanayii Derneği (OSD) 51. Olağan Genel Kurul Toplantısı’na katılan Sanayi ve Teknoloji Bakanı Mehmet Fatih Kacır, “2026’nın ilk iki ayında da otomotiv ihracatında olumlu bir tablo yaşıyoruz. Ticari araç ve otobüs üretiminde Avrupa’nın lideriyiz. Son 23 yılda; 169 Ar-Ge merkezinin, 36 tasarım merkezinin ve teknoparklarımızda faaliyet gösteren 132 girişimin otomotiv sektörümüzün inovasyon kapasitesini besleyen projelerini destekledik.” dedi ve şunları aktardı: “Otomotiv sektörümüz; yatırım, istihdam, üretim ve ihracat eksenli kalkınma yolculuğumuzda ortaya koyduğu performansla hususi bir takdiri hak ediyor. Ana sanayide 60 bine yakın, tedarik sanayinde de 250 bin aşkın nitelikli istihdam sağlayan sektörümüz için geçtiğimiz yıl, hanesine yeni kazanımlar eklediği bir sene oldu. Geçtiğimiz yıl otomotiv üretimimiz; 1 milyon 446 bine ulaştı, ihracatımız 41,5 milyar dolarla rekor tazeledi. 2026’nın ilk iki ayında otomotiv ihracatında olumlu bir tablo yaşıyoruz. Ticari araç ve otobüs üretiminde Avrupa’nın lideriyiz. Otomotiv üretiminde ilk beş oyuncu arasındayız. Sanayi ve Teknoloji Bakanlığı […]

Sanayi ve Teknoloji Bakanı Mehmet Fatih Kacır, otomotiv sektörü hakkında açıklamalarda bulundu yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

DJI, 360 derece çekim yapabilen drone modeli Avata 360’ı tanıttı

DJI Avata 360

DJI Avata 360DJI bugün 360 derece çekim yapabilen drone modeli Avata 360’ı resmi olarak görücüye çıkardı. 455 gramlık drone, şirketin resmi açıklamasına göre 23 dakika boyunca havada kalabiliyor ve iki adet 1/1,1 inç boyutunda kare CMOS sensörü bir araya getiriyor. 64 megapiksellik sensörlerle 360 derecelik 8K 60 fps D-Log M video çekebilen model, istenirse 360 derecelik fotoğraflar da üretebiliyor. İstenirse tek bir kamerayı kullanarak da (4K 60 fps) video ve fotoğraf kaydedebilen drone, gelişmiş kaza önleme sistemleriyle geliyor ve pervaneleri koruyan tasarımıyla oldukça kullanışlı görünüyor. İlk olarak Çin’de satışa sunulacak Avata 360’ın başlangıç fiyatı yaklaşık 540 dolar seviyesinde yer alıyor.

DJI, 360 derece çekim yapabilen drone modeli Avata 360’ı tanıttı yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

Volkswagen, Skoda’yı Çin pazarından çekme kararı aldı

Skoda Volkswagen

Skoda VolkswagenBugün yapılan resmi açıklamaya göre Volkswagen, çatısı altında yer alan markalardan Skoda’yı Çin pazarından çekme kararı aldı. Çin’de 2021 yılında 71.000 adet, 2022 yılında 44.600 adet, 2023 yılında 22.800 adet, 2024 yılında 17.500 adet, 2025 yılında ise 15.000 adet araç sattığı açıklanan marka, yerli üreticilerin çok iddialı elektrikli otomobilleriyle domine ettiği Çin otomobil pazarındaki rekabet gücünü tamamen kaybetmiş durumda.

Volkswagen, Skoda’yı Çin pazarından çekme kararı aldı yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

OSD’nin Yönetim Kurulu Başkanlığı’na yeniden Cengiz Eroldu seçildi

OSD’nin Yönetim Kurulu Başkanlığı’na yeniden Cengiz Eroldu seçildi

OSD’nin Yönetim Kurulu Başkanlığı’na yeniden Cengiz Eroldu seçildiOtomotiv Sanayii Derneği (OSD), 51’inci Olağan Genel Kurulu’nu gerçekleştirdi. Cengiz Eroldu beşinci döneminde yeniden Başkan olarak seçilirken, Başkan Vekili Süer İsmail Sülün, Başkan Yardımcıları Güven Özyurt, Lionel Jaillet ve Murat Bülbül, Muhasip Üye Yusuf Tuğrul Arıkan oldu. T.C. Sanayi ve Teknoloji Bakanı Mehmet Fatih Kacır, Bakan Yardımcısı Zekeriya Coştu ve T.C. Ticaret Bakan Yardımcısı Özgür Volkan Ağar’ın katıldığı Genel Kurul’da konuşan OSD Başkanı Cengiz Eroldu, “2025 yılı, Türk otomotiv sanayisinin yatırımlarına devam ettiği, yeni projelerini hayata geçirdiği, üretim ve mühendislik gücü ile ihracat kapasitesini bir kez daha ortaya koyduğu bir yıl oldu. 41,5 milyar dolarlık rekor seviyede gerçekleşen ihracat, sanayinin uluslararası pazarlardaki güçlü konumunu teyit etti. İçinde bulunduğumuz dönemde küresel ortamda yaşanan ticaret savaşları ve değişen dünya düzeni bizleri daha belirsiz, daha rekabetçi ve daha yerelleşme odaklı politikalar ile karşı karşıya bırakıyor. Bu yeni dönemde de önceliğimiz, kamu başta olmak üzere tüm paydaşlarımız ile iş birliği içerisinde, sanayimizin güçlü yönlerini […]

OSD’nin Yönetim Kurulu Başkanlığı’na yeniden Cengiz Eroldu seçildi yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

OpenAI, ChatGPT’nin “yetişkin” modunu daha çıkmadan rafa kaldırdı

OpenAI ChatGPT LOG Tasarım

OpenAI ChatGPT LOG TasarımOpenAI şirketinin CEO’su Sam Altman, geçtiğimiz yıl X hesabından yaptığı bir açıklamada, “ChatGPT’yi başlangıçta ruh sağlığıyla ilgili konularda dikkatli olmak adına daha kısıtlayıcı bir biçimde tasarladık. Bunun, ruhsal sorunu olmayan kullanıcıların elde ettiği deneyimi bozduğunu biliyoruz. Ancak konunun ciddiyeti nedeniyle her şeyi doğru yapmamız gerekiyordu. Geliştirme çalışmalarıyla ruh sağlığıyla ilgili büyük riskleri azalttık ve artık elimizde bu sürece karşı oldukça güçlü yeni araçlar var. Bu sayede getirdiğimiz kısıtlamaları çoğu durumda güvenli bir şekilde gevşetebileceğiz. Aralık ayında yaş doğrulama sisteminin tam olarak devreye alınmasıyla birlikte, ‘yetişkin kullanıcılara yetişkin gibi davranma’ ilkemiz kapsamında doğrulanmış yetişkin kullanıcılar için erotik içerikler de dâhil olmak üzere daha geniş etkileşim özgürlükleri sağlayacağız.” demişti. Altman, cinselleştirilmiş yapay zeka içeriklerinin toplum üzerinde yaratabileceği zararlı etkiler nedeniyle çalışanlar ve yatırımcıların tepkisini çektiği için tamamen rafa kaldırıldığı aktarılan altyapıya ilişkin yaptığı son açıklamada ise, “Yetişkin modunun çıkışını biraz erteliyoruz. Odağımızı kullanıcılar için daha önemli olan konulara çevirdik. Genel zekayı artırmaya, […]

OpenAI, ChatGPT’nin “yetişkin” modunu daha çıkmadan rafa kaldırdı yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

How I Built White-Label Document Sharing for Client-Facing Docs

When people send proposals, pitch decks, NDAs, and other client-facing documents, they usually want the recipient focused on their brand, not the software powering the experience.

That was the motivation behind a feature I recently shipped in DocBeacon: white-label document sharing for Pro users.

The idea sounds simple:

Let users attach a custom brand name, logo, and website URL to shared documents.

But once I got into implementation, it turned into an interesting mix of product design, access control, storage, validation, and fallback behavior.

This post is a short breakdown of how I approached it.

The problem

Before this feature, a shared document was still visually branded as DocBeacon throughout the viewing flow.

That was fine for some use cases, but not ideal for teams sending:

consulting proposals
investor decks
sales documents
sensitive client materials

In those workflows, brand consistency matters. If someone is sharing a high-value proposal, they usually want the experience to reinforce their credibility, not mine.

So the requirement became:

Let eligible users show their own branding across the document viewing experience, while keeping the system safe and predictable.

What the feature needed to support

At a high level, I wanted users to be able to configure:

a display name
a logo
a website URL
an on/off toggle for branding

And once enabled, that branding should appear in places like:

the document viewer header
attribution text
shared document metadata
other client-facing viewer touchpoints

I also wanted a clean fallback path. If branding data was incomplete, invalid, or the user’s plan didn’t allow the feature, the system should quietly fall back to the default DocBeacon brand.

The core design decision: resolve branding once

One of the first decisions I made was to avoid scattering branding logic across multiple rendering layers.

Instead of asking every page or component to figure out branding on its own, I used a single resolution step:

Check whether the user is allowed to use the feature
Check whether branding is enabled
Check whether enough valid branding data exists
Return either:
the user’s brand config, or
the default platform brand

In pseudocode:

**function resolveBranding(user):
    canBrand = planAllowsBranding(user.plan)
    hasIdentity = user.displayName OR user.logoPath
    enabled = user.brandingEnabled AND canBrand AND hasIdentity

    if enabled:
        return {
            name: user.displayName,
            logoUrl: buildAssetUrl(user.logoPath),
            websiteUrl: normalizeUrl(user.websiteUrl)
        }

    return defaultBrand**

This helped keep the rest of the system simple. Viewer pages didn’t need to know all the rules. They just consumed a resolved branding object.

Access control

This feature is only available on Pro+ plans, so access control had to be built into the feature itself, not just the UI.

That means even if someone somehow submits branding settings through an API call or stale client state, the backend still needs to enforce eligibility.

The check is conceptually simple:

canUseBranding(user):
    return user.plan in ["pro", "business", "enterprise"]

I treated this as a server-side rule first, and a UI rule second.

That’s important because frontend gating alone is never enough for plan-restricted features.

Asset storage for logos

For logo uploads, I wanted a storage layer that was simple, cheap, and fast to serve publicly.

I used Cloudflare R2 for uploaded branding assets.

The flow looks roughly like this:

User uploads a PNG or JPG
Backend validates file type and size
File is stored under a user-scoped path
The app stores only the storage path in the user record
A helper builds the public asset URL when needed

In pseudocode:

uploadLogo(file, user):
    assert file.type in ["image/png", "image/jpeg"]
    assert file.size <= MAX_LOGO_SIZE

    path = "branding/" + user.id + "/" + generateFileName(file)
    storage.put(path, file)

    saveUserBranding(user.id, { logoPath: path })

And later:

buildAssetUrl(path):
    return CDN_BASE_URL + "/" + path

I preferred storing the path rather than a fully expanded URL in the database, because it keeps storage concerns separate from delivery concerns.

URL validation was the trickiest part

The hardest part of this feature was not rendering a logo.

It was letting users attach a website URL safely.

On the surface, “enter your website” sounds trivial. In practice, it needs guardrails.

I did not want to allow:

localhost
private network IPs
credential-based URLs like user:[email protected]
unsafe schemes like javascript: or file:

So I treated URL handling as a normalization + validation pipeline.

The job of that pipeline is:

parse the input
normalize format
require http or https
reject unsafe hosts
reject credentials
return either a safe URL or null

In pseudocode:

normalizeUrl(input):
    if input is empty:
        return null

    parsed = parseUrl(input)

    if parsed.scheme not in ["http", "https"]:
        return null

    if parsed.hasCredentials:
        return null

    if isLocalhost(parsed.host) or isPrivateIp(parsed.host):
        return null

    return parsed.normalizedHref

This kind of defensive validation matters because branding fields are user-controlled input, and user-controlled input always deserves scrutiny.

Fallback behavior matters more than people think

A lot of polish in a feature like this comes from handling invalid states well.

For example:

branding is toggled on, but no logo is uploaded yet
the user entered an invalid URL
the user downgraded from Pro to Free
an asset was deleted or unavailable
branding data is partially filled out

In all of those cases, I wanted the document experience to remain stable.

So instead of letting the UI break or showing half-configured branding, I default to the platform brand whenever the custom brand can’t be resolved safely.

That gives the system a predictable contract:

Either show a fully valid custom brand, or show the default brand.

No broken middle state.

Why I like this implementation

What I like about this feature is that it makes the product less visible in the right places.

For this use case, that’s the goal.

The product should support the sender’s identity, not compete with it.

From an engineering point of view, I also like that the system is built around a few clear principles:

central branding resolution
server-side plan enforcement
explicit URL normalization
safe asset handling
reliable fallback behavior

The final result feels simple to the user, which usually means the internal rules are doing their job.

What I’d improve next

A few things I’d likely add next:

custom domains for shared links
better branding previews in settings
image processing for uploaded logos
audit logging for branding changes
more granular per-document branding controls

That would take it from “account-level branding” to a more flexible identity layer.

Final thought

This started as a branding feature, but it ended up being a good reminder that “simple UX” often sits on top of a lot of backend discipline.

If you’re building anything user-configurable and client-facing, the hard part usually isn’t just rendering the settings.

It’s defining the rules for what’s allowed, what’s safe, and what happens when the input is incomplete.

If you’re curious, the product is DocBeacon: https://docbeacon.io

Understanding a Real-World Spring Boot Project Structure (Best Practices)

🧩 Understanding a Real-World Spring Boot Project Structure (Best Practices)

When you start working with Spring Boot, everything feels simple… until your project grows.

Then suddenly:

😵Too many files
😵‍💫Confusing structure
❌Hard to maintain code

In this article, I’ll walk you through a clean and scalable Spring Boot project structure based on a real example.

📁 Project Overview

Here’s a simplified view of the structure:

src/main/java/org.sid
├── controllers
├── dto
├── entities
├── enums
├── mappers
├── repositories
├── securityKeycloak
├── services

Each layer has a clear responsibility, which makes the application maintainable and scalable.

🎯 1. Entities (entities)

Represents database tables.

🧠 2. Repository Layer (repositories)

This layer communicates with the database.

👉 Uses Spring Data JPA

✅ No implementation needed — Spring generates it automatically!

🗄️ 3. DTOs (dto)

DTO = Data Transfer Object
👉 Used to send data between layers safely

✅ Why use DTOs?
_Protect sensitive Data:_
In a Spring Boot application, a DTO (Data Transfer Object) is used to transfer data between layers, especially between the backend and the client.
It is used to protect sensitive data: entities often contain sensitive fields such as passwords. If you return these entities directly, it can create a security risk.

Control API response:
A DTO (Data Transfer Object) allows you to decide exactly what data is sent to the client instead of exposing your full Entity.

🔁 4. Mappers (mappers)

Convert between Entity ↔ DTO

public class AccountMapper {
public static AccountDTO toDTO(Account account) {
// mapping logic
}
}

💡 You can also use MapStruct for cleaner code.

🔄 5. Service Layer (services)

This is where business logic lives.

👉 Acts as a bridge between controller and repository

@Service
public class AccountService {

public List<AccountDTO> getAllAccounts() {
    // business logic here
}

}
example:

✅ Responsibilities:

-    Business rules
-    Data processing
-    Validation

📦 6.Controllers Layer (controllers)

This is the entry point of your application.

👉 Handles HTTP requests (GET, POST, PUT, DELETE)

Example:

✅ Best Practice:
Keep controllers thin , No business logic here

⚠️ Important:
Do NOT expose entities directly in APIs

🔢 7. Enums (enums)

Used for fixed values like:

🔐 8. Security (securityKeycloak)

Handles authentication & authorization.

👉 In my case: Keycloak integration

Responsibilities:

  • JWT validation
  • User roles
  • Secure endpoints

🔄 How Everything Works Together

Here’s the flow:


spring Boot Flow Architecture

  1. Client sends HTTP request
  2. Controller receives it
  3. Service processes logic
  4. Repository fetches data
  5. Mapper converts Entity → DTO
  6. Response returned to client

🚀 Best Practices Recap

  ✅ Use layered architecture
  ✅ Never expose entities
  ✅ Keep controllers clean
  ✅ Use DTOs + Mappers
  ✅ Separate business logic in services

🎯 Conclusion

A well-structured Spring Boot project is the key to building scalable and maintainable applications.

Happy coding 🚀