Programowanie

Pierwsze README #git napisane przez #linustorvalds w 2005. W następnym commicie który dotyka tego pliku obok zmienił .dircache/index -> .git/index.

https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-2b7814d3fca2e99e56c51b6ff2aa313ea6e9da6424804240aa8ad891fdfe0900

> GIT - the stupid content tracker
>
> "git" can mean anything, depending on your mood.
>
> - random three-letter combination that is pronounceable, and not
> actually used by any common UNIX command. **The fact that it is a
> mispronounciation of "get" may or may not be relevant.**
> - stupid. contemptible and despicable. simple. Take your pick from the
> dictionary of slang.
> - "global information tracker": you're in a good mood, and it actually
> works for you. Angels sing, and a light suddenly fills the room.
> - "goddamn idiotic truckload of sh*t": when it breaks
>
> This is a stupid (but extremely fast) directory content manager. It
> doesn't do a whole lot, but what it _does_ do is track directory
> contents efficiently.
>
> There are two object abstractions: the "object database", and the
> "current directory cache".
>
> The Object Database (SHA1_FILE_DIRECTORY)
>
> The object database is literally just a content-addressable collection
> of objects. All objects are named by their content, which is
> approximated by the SHA1 hash of the object itself. Objects may refer
> to other objects (by referencing their SHA1 hash), and so you can build
> up a hierarchy of objects.
>
> There are several kinds of objects in the content-addressable collection
> database. They are all in deflated with zlib, and start off with a tag
> of their type, and size information about the data. The SHA1 hash is
> always the hash of the _compressed_ object, not the original one.
>
> In particular, the consistency of an object can always be tested
> independently of the contents or the type of the object: all objects can
> be validated by verifying that (a) their hashes match the content of the
> file and (b) the object successfully inflates to a stream of bytes that
> forms a sequence of + + <ascii decimal
> size> + <byte\\0> + .
>
> BLOB: A "blob" object is nothing but a binary blob of data, and doesn't
> refer to anything else. There is no signature or any other verification
> of the data, so while the object is consistent (it _is_ indexed by its
> sha1 hash, so the data itself is certainly correct), it has absolutely
> no other attributes. No name associations, no permissions. It is
> purely a blob of data (ie normally "file contents").
>
> TREE: The next hierarchical object type is the "tree" object. A tree
> object is a list of permission/name/blob data, sorted by name. In other
> words the tree object is uniquely determined by the set contents, and so
> two separate but identical trees will always share the exact same
> object.
>
> Again, a "tree" object is just a pure data abstraction: it has no
> history, no signatures, no verification of validity, except that the
> contents are again protected by the hash itself. So you can trust the
> contents of a tree, the same way you can trust the contents of a blob,
> but you don't know where those contents _came_ from.
>
> Side note on trees: since a "tree" object is a sorted list of
> "filename+content", you can create a diff between two trees without
> actually having to unpack two trees. Just ignore all common parts, and
> your diff will look right. In other words, you can effectively (and
> efficiently) tell the difference between any two random trees by O(n)
> where "n" is the size of the difference, rather than the size of the
> tree.
>
> Side note 2 on trees: since the name of a "blob" depends entirely and
> exclusively on its contents (ie there are no names or permissions
> involved), you can see trivial renames or permission changes by noticing
> that the blob stayed the same. However, renames with data changes need
> a smarter "diff" implementation.
>
> CHANGESET: The "changeset" object is an object that introduces the
> notion of history into the picture. In contrast to the other objects,
> it doesn't just describe the physical state of a tree, it describes how
> we got there, and why.
>
> A "changeset" is defined by the tree-object that it results in, the
> parent changesets (zero, one or more) that led up to that point, and a
> comment on what happened. Again, a changeset is not trusted per se:
> the contents are well-defined and "safe" due to the cryptographically
> strong signatures at all levels, but there is no reason to believe that
> the tree is "good" or that the merge information makes sense. The
> parents do not have to actually have any relationship with the result,
> for example.
>
> Note on changesets: unlike real SCM's, changesets do not contain rename
> information or file mode chane information. All of that is implicit in
> the trees involved (the result tree, and the result trees of the
> parents), and describing that makes no sense in this idiotic file
> manager.
>
> TRUST: The notion of "trust" is really outside the scope of "git", but
> it's worth noting a few things. First off, since everything is hashed
> with SHA1, you _can_ trust that an object is intact and has not been
> messed with by external sources. So the name of an object uniquely
> identifies a known state - just not a state that you may want to trust.
>
> Furthermore, since the SHA1 signature of a changeset refers to the
> SHA1 signatures of the tree it is associated with and the signatures
> of the parent, a single named changeset specifies uniquely a whole
> set of history, with full contents. You can't later fake any step of
> the way once you have the name of a changeset.
>
> So to introduce some real trust in the system, the only thing you need
> to do is to digitally sign just _one_ special note, which includes the
> name of a top-level changeset. Your digital signature shows others that
> you trust that changeset, and the immutability of the history of
> changesets tells others that they can trust the whole history.
>
> In other words, you can easily validate a whole archive by just sending
> out a single email that tells the people the name (SHA1 hash) of the top
> changeset, and digitally sign that email using something like GPG/PGP.
>
> In particular, you can also have a separate archive of "trust points" or
> tags, which document your (and other peoples) trust. You may, of
> course, archive these "certificates of trust" using "git" itself, but
> it's not something "git" does for you.
>
> Another way of saying the same thing: "git" itself only handles content
> integrity, the trust has to come from outside.
>
> Current Directory Cache (".dircache/index")
>
> The "current directory cache" is a simple binary file, which contains an
> efficient representation of a virtual directory content at some random
> time. It does so by a simple array that associates a set of names,
> dates, permissions and content (aka "blob") objects together. The cache
> is always kept ordered by name, and names are unique at any point in
> time, but the cache has no long-term meaning, and can be partially
> updated at any time.
>
> In particular, the "current directory cache" certainly does not need to
> be consistent with the current directory contents, but it has two very
> important attributes:
>
> (a) it can re-generate the full state it caches (not just the directory
> structure: through the "blob" object it can regenerate the data too)
>
> As a special case, there is a clear and unambiguous one-way mapping
> from a current directory cache to a "tree object", which can be
> efficiently created from just the current directory cache without
> actually looking at any other data. So a directory cache at any
> one time uniquely specifies one and only one "tree" object (but
> has additional data to make it easy to match up that tree object
> with what has happened in the directory)
>
>
> and
>
> (b) it has efficient methods for finding inconsistencies between that
> cached state ("tree object waiting to be instantiated") and the
> current state.
>
> Those are the two ONLY things that the directory cache does. It's a
> cache, and the normal operation is to re-generate it completely from a
> known tree object, or update/compare it with a live tree that is being
> developed. If you blow the directory cache away entirely, you haven't
> lost any information as long as you have the name of the tree that it
> described.
>
> (But directory caches can also have real information in them: in
> particular, they can have the representation of an intermediate tree
> that has not yet been instantiated. So they do have meaning and usage
> outside of caching - in one sense you can think of the current directory
> cache as being the "work in progress" towards a tree commit).

#programowanie

W końcu, po około pół roku wytężonej pracy (i odpoczynku), mogę przedstawić nową wersję Czkawki/Krokieta/Cedinii 12.0 do wyszukiwania duplikatów, podobnych obrazów, wideo i wielu innych dziwnych rzeczy.

Ponieważ mój poprzedni post dotyczący problemów z dystrybucją aplikacji na Androida do szerszego grona odbiorców spotkał się z taktownym milczeniem, zostałem zmuszony do wydania aplikacji bez publikacji w zewnętrznych sklepach.

Zapewne rzuciła się wam w oczy nowa, dość bezsensowna (choć zapewne swojsko brzmiąca) nazwa - Cedinia. Jest to nowa aplikacja na Androida, instalowana z pliku APK (ponieważ nie znalazłem innej sensownej metody dystrybucji). Funkcjonalnie oferuje niemal wszystkie narzędzia dostępne w Krokiet, ale jej interfejs został dostosowany do ekranów dotykowych (testowana była jednak tylko na jednym moim telefonie, więc na innych urządzeniach mogą wystąpić problemy z UI).

Co do wersji gtk, to porzuciłem jej rozwój, bo przez długi czas sprawiała problemy - od braku uruchamiania się u części użytkowników, przez crashe przy wklejaniu, po problemy ze skalowaniem interfejsu. Dzięki temu na Windowsie pozostanie dystrybowana jedna binarka exe, zamiast paczki zip z wieloma zależnymi dllkami wymaganymi przez GTK.

Jak w każdej wersji, pojawiło się też kilka nowości tj. porównywarka obrazów, menu kontekstowe, szybka (choć mniej dokładna) weryfikacja uszkodzonych plików z użyciem ffprobe, nowe okno zaznaczania elementów, osobne przyciski do trwałego usuwania oraz przenoszenia do kosza czy także redukcja szumów w module optymalizacji wideo (opartym o ffmpeg).

Artykuł na medium, gdyby ktoś szerzej chciał o nowej wersji przeczytać - https://medium.com/@qarmin/krokiet-czkawka-12-0-c5dad2116793

Repozytorium — https://github.com/qarmin/czkawka

Pliki do pobrania wraz z listą zmian — https://github.com/qarmin/czkawka/releases

Licencja — MIT/GPL w zależności od programu (czyli w skrócie za darmo)

#programowanie
#tworczoscwlasna
#rustlang

Im więcej tworzę kodu z wykorzystaniem agentów AI, tym bardziej widzę, jak istotnie zmienia się moja praca. Jednym z takich aspektów jest to, jak postrzegam dług technologiczny. Swoje przemyślenia o tym, co dokładnie zmienia wykorzystanie AI w obsłudze i zaciąganiu długu

#programista15k #wolontariat

Kochani bardzo prosze was o wypełnienie ankiety o zdrowiu psychicznym u programistów, za chwilę uwalę magisterkę przez zbyt małą ilość odpowiedzi, proszę o pomoc :(
https://forms.gle/YLE1rhAhBJHSbhQP7

W ramach zabawy z ClaudeCode stworzyłem sobie wyszukiwarkę ebooków i audiobooków w Legimi, EmpikGo, Storytel i Audiotece.

Empik jak zwykle był problematyczny, bo nie może mieć normalnego searcha, ale ostatecznie wyszło całkiem spoko :)
#claude #ksiazki #czytajzwujkiem #programowanie

W świecie coraz częstszej integracji z LLM-ami i innymi zewnętrznymi usługami ich stabilność staje się realnym problemem architektonicznym. Usługi potrafią być wolne, przeciążone albo niedostępne, co łatwo może przenosić się na naszą aplikację i naszych klientów. Jednym ze

Zaczynasz projekt, rozpisujesz taski, plan działania, technologie… i już na starcie odechciewa Ci się wszystkiego? Mam wrażenie, że wiele osób nie kończy swoich projektów nie dlatego, że są za słabe. Tylko dlatego, że próbują od razu zrobić wszystko idealnie. W nowym newsletterze

za⁎⁎⁎⁎sta platforma #github nie może stworzyć pull requesta xD

co polecacie? selfhosted odpada. GitLab znam, więc to będzie mój domyślny wybór, bo tak się żyć nie da.

zapraszam na imprezę https://ghstatus.party/

#programowanie #gownowpis

jakby mi tak odpowiedział stażysta to nie wiem czy bym go zdążył wy⁎⁎⁎ać zanim bym go rozjebał

#programowanie #gownowpis #sztucznainteligencja

Po przejściu do IT potrafiłam przez 8h siedzieć nad cudzym kodem i nadal nie wiedzieć co się tam właściwie dzieje. Pierwszego dnia usłyszałam też, że wdrożenie zajmie… 2 lata. W najnowszym newsletterze piszę o: zderzeniu spokojnej pracy z rzeczywistością IT, czytaniu kodu

Google właśnie zaorał Gemini CLI:
https://github.com/google-gemini/gemini-cli/discussions/27274

Pozornie niewinne ale tak naprawdę to właśnie pokazali mega faka wszystkim kontrybutorom i ludziom którzy po prostu z tego korzystali. Dlaczego? Bo Gemini CLI od początku było reklamowane jako open source projekt przy którym każdy może pomóc. I ludzie faktycznie pomagali, zrobiono ponad 6k PR i aplikacja od swojej premiery przeszłą ogromną zmianę a programiści ją naprawdę polubili (104k gwiazdek na GH) bo była po prostu bardzo użyteczna i łatwa w obsłudze.

I teraz postanowili że wszystko to pójdzie w piach, bo przepisali to na Go ale nie otwierając kodu a Gemini CLI pozostanie jako aplikacja dla klientów enterprise. Czyli, że własnie społeczność im udoskonaliła produkt z którego już nie będą mogli korzystać jak wcześniej i jednocześnie są zmuszeni do przejścia na gorszy zamknięty produkt który na ten moment ma mniej funkcji czyli Antigravity CLI. Nowa apka na bank nie będzie miała tak szybko łatanych bugów i nowych ficzerów no bo użytkownicy już nie będą mogli sami ich dodawać. Dodatkowo z tego co rozumiem będzie ona głównie służyła jako backend dla Antigravity a funkcjonalność CLI schodzi na drugi plan.

Teraz pytanie do was. Jaka według was jest najlepsza alternatywa dla Gemini CLI? Bo nie zamierzam już płacić Google po tym co zrobili. Moje must have wymagania to aby było dostępne na Linuxie i działało w terminalu. Mile widziane aby było open source oraz żeby nie puściło mnie z torbami z rachunkami za tokeny.
#programowanie #ai #google #programista15k

14 etapów rekrutacji.\ 600 kandydatów.\ 4 miesiące procesu.\ 1 osoba dostanie pracę. I zaczynam się zastanawiać - czy firmy nadal szukają najlepszych specjalistów, czy już najbardziej wytrwałych ludzi, którzy nie odpadną po 12 rozmowie? W nowym wpisie piszę o:\ - absurdach rekrutacji w

#programowanie #github #cyberbezpieczenstwo . źródło

Ale mnie wkurwia niemożliwie ze trzeba będzie teraz pewnie ze dwa lata czekać żeby się wielkie projekty data center wyjebały i ceny RAMu wróciły do normy jak będą to wyprzedawać.

#programowanie #zalesie #komputery #technologia #sztucznainteligencja

Czy tylko programiści potrafią spędzić kilka godzin nad kodem… tylko po to, żeby finalnie go usunąć? :sweat_smile: I nie - nie dlatego, że był zły. Wręcz przeciwnie. Kod działał. Feature był gotowy. Problem rozwiązany. Po prostu w pewnym momencie przychodzi TA myśl:\ „meh…

>Me piszący side project z działającym PoCem pierwszego dnia

>Me kończący side project miesiąc później

#programowanie #programowanko #pamietniczek

Dwa tygodnie temu napisałam o feature'ach, których nikt nie potrzebował. Jeden z czytelników powiedział wprost:  zdiagnozowałaś problem, ale nie dałaś rozwiązania. No to masz rozwiązanie. W tym wydaniu: jedno małe pytanie, które może uratować Cię przed tygodniami bezsensownej pracy.

Ile godzin dziennie naprawdę piszecie dobry kod? Pytam bo sama dochodzę do wniosku, że to realnie jakieś 3-4h… Ciekawa jestem czy u Was z doświadczeniem to się zmieniło? Swoją perspektywę umieściłam w najnowszym wpisie

Masz wrażenie, że dowozisz funkcjonalności, które… nikogo nie obchodzą? Feature “na wczoraj”, wdrożony, zakomunikowany… i cisza. Zero feedbacku, zero usage, za to rosnąca złożoność systemu, kolejne wyjątki i coraz większy dług technologiczny. W którym momencie przestajemy