Still looking for jobs and look what I found:

Title starts off bad, they can't even spell Android LOL, then go on to ask for someone with experience with Xcode and objective-c, interface builder and basically iOS.

How are these people able to create job listings without any actual research?

Thought I'd add the last line of my similar rant,

Lol What a fucking joke...

FUCK YOU INTERFACE BUILDER.
FUCK YOU XCODE.
FUCK YOU APPLE.

import LongRantKit
import NonRantKit
import TldrKit

I don't like stickers on my laptop because it clutters it up. But today I realized the importance of them.

A few months ago I was sitting at a coffee shop working on a paper and I noticed a guy with this cool sticker on a MacBook Pro: it had the integral symbol to the left of the Apple logo, and to the right of it a lowercase d and another Apple logo. It took me a few hours to realize what it meant, but I finally did and at that point I also guessed that not many people know what it is.

So I, as antisocial as I am, I finish up my work and before I leave I walk up to him and say hi. At this point I'm a senior in high school and I learn he's a junior in the same college I plan to attend. We talked a little before I had to leave and got to know each other somewhat.

After I leave I find him on Instagram and Facebook and friend him and such.

Recently I posted a picture saying I had recently joined the Apple Developer Team, and also recently reposted a memory on Facebook from 5 years ago that was a screen capture of an iPhone 4 simulator running iOS 5 showing off one of my first apps.

Then yesterday I get a message from the guy I met at the coffee shop asking for some help with an iOS project he's working on. We decide to meet today and I spend the entire morning showing him the basics of Swift, Xcode, Interface Builder, etc. I feel like I really helped him jumpstart his app and helped him understand the basics of different concepts.

If he didn't have that integral sticker on his laptop I would have never had this opportunity to finally share some iOS development experience.

For this I would like to thank my high school calculus teacher, with whom I spent many classes at Starbucks because I was an only student. I'd like to thank laptop stickers, and finally I would like to thank the coffee shop.

TL;DR: Said hi to a guy with an integral sticker on his laptop, a few months later he approaches me for help understanding iOS development.

While reviewing a PR from one of our newer FE devs, I ended up spending more time than I would like mulling over its composition. The work was acceptable for the most part; the code worked. The part that got me was the heavy usage of options objects.

When encountering the options object pattern (or anti-pattern, at times) in complex scenarios, I have to resist the urge to stop whatever I'm doing and convert it to the builder pattern/smack them in the head with a software design manual. As much as I would like to, code janitor is one of the least valuable activities I engage in daily, and consistently telling someone to go back to the drawing board for work that is functional, but not excellent is a great way to kill morale. Usually, I'll add a note on the PR, approve it, add a brown bag or two on that sort of thing, and make attendance mandatory for repeat slackers. Skills building and catharsis all rolled up in a tiny ball of investing in your people.

Builders make things so much cleaner; they inform users what actions are available in a context; they tend to be immutable, and when done well, provide an intuitive fluent interface for configuration that removes the guesswork. As a bonus, they're naturally compositional, so you can pass it around and accumulate data and only execute the heavy lifting bits when you need to. As a bonus, with typescript, the boilerplate is generally reduced as well, even without any code generation. And they're not just a dumping ground for whatever shit someone was too lazy to figure out how to integrate into the API neatly.

They're more work in js-land, sure; you can't annotate @builder like with Lombok, but they're generally not all that much work and friendlier to use.

I came from Android, in the xml you can put simply "match_parent" or "wrap_content", or align right or left.

Then I tried to use Xcode interface builder for iOS. now I am sad and feeling bad. why Apple, why

Earlier this year, we built a custom gift box builder for a local popcorn company. I had decided to use vue.js for the interface which was really fun to learn.

I hadn't used any reactive frameworks like vue before this project, but I was surprised how easy it was to use, and it was so satisfying watching the frontend change just by modifying the data. I was able to easily add little transition animations when the states changed which was really fun too (something that would be really tedious otherwise).

That's was probably the most fun I've had on a project in a while.

as an Android dev of a few years, I HATE iOS. Coding on XCode vs Android Studio is a nightmare. The error logs are terrible in comparison to Java. Obj-C is a nightmare. Swift is cool, I'll admit, but I could probably build better interfaces that scale per device on an Etch-A-Sketch. Instead of creating a layout in Interface Builder that worked for all devices (freakin' impossible) I instead opted to save myself some time and get a reference of the constraints and adjust them PER DEVICE. If that's not shitty code practice, I don't know what is. when I code iOS apps I feel like I'm in college again, just doing whatever the hell I can to get a project done with. the problem with mobile dev is that, when you can, you want to target both OSes. typically I do Android first and switch to iOS. I probably should do iOS first and then work on the Android version

That moment when you change a color property in the interface builder and Xcode decides to go batshit crazy then crash.

I hate programmatic auto layout. It's such a mess! Simple shit like cells that can easily be defined in a .nib become spaghetti coded messes that violate every good programming practice ever. Want to recreate the same style of cell again? Good luck reverse engineering the hieroglyphics your teammate wrote when creating the layout by hand. Never mind a whole bunch of useless shit is done in code that could easily be defined via runtime attributes through the storyboard. But why learn a new approach? Cause job security. Or because for some reason Interface Builder tools are seen as "too hard" or "not scalable" to use.. fuck me.

Sometimes in our personal projects we write crazy commit messages. I'll post mine because its a weekend and I hope someone has a well deserved start. Feel free to post yours, regex out your username, time and hash and paste chronologically. ISSA THREAD MY DUDES AND DUDETTES
--
Initialization of NDM in Kotlin
Small changes, wiping drive
Small changes, wiping drive
Lottie, Backdrop contrast and logging in implementation
Added Lotties, added Link variable to Database Manifest
Fixed menu engine, added Smart adapter, indexing, Extra menus on home and Calendar
b4 work
Added branch and few changes
really before work
Merge remote-tracking branch 'origin/master'
really before work 4 sho
Refined Search response
Added Swipe to menus and nested tabs
Added custom tab library
tabs and shh
MORE TIME WASTED ON just 3 files
api and rx
New models new handlers, new static leaky objects xd, a few icons
minor changes
minor changesqwqaweqweweqwe
db db dbbb
Added Reading display and delete function
tryin to add web socket...fail
tryin to add web socket...success
New robust content handler, linked to a web socket. :) happy data-ring lol
A lot of changes, no time to explain
minor fixes ehehhe
Added args and content builder to content id
Converted some fragments into NDMListFragments
dsa
MAjor BiG ChANgEs added Listable interface added refresh and online cache added many stuff
MAjor mAjOr BiG ChANgEs added multiClick block added in-fragment Menu (and handling) added in-fragment list irem click handling
Unformatted some code, added midi handler, new menus, added manifest
Update and Insert (upsert) extension to Listable ArrayList
Test for hymnbook offline changing
Changed menuId from int to key string :) added refresh ...global... :(
Added Scale Gesture Listener
Changed Font and size of titlebar, text selection arg. NEW NEW Readings layout.
minor fix on duplicate readings
added isUserDatabase attribute to hymn database file added markwon to stanza views
Home changes :)
Modular hymn Editing
Home changes :) part 2
Home changes :) part 3
Unified Stanza view
Perfected stanza sharing
Added Summernote!!
minor changes
Another change but from source tree :)))
Added Span Saving
Added Working Quick Access
Added a caption system, well text captions only
Added Stanza view modes...quite stable though
From work changes
JUST a [ush
Touch horizontal needs fix
Return api heruko
Added bible index
Added new settings file
Added settings and new icons
Minor changes to settings
Restored ping
Toggles and Pickers in settings
Added Section Title
Added Publishing Access Panel
Added Some new color changes on restart. When am I going to be tired of adding files :)
Before the confession
Theme Adaptation to views
Before Realm DB
Theme Activity :)
Changes to theme Activity
Changes to theme Activity part 2 mini
Some laptop changes, so you wont know what changed :)
Images...
Rush ourd
Added palette from images
Added lastModified filter
Problem with cache response
works work
Some Improvements, changed calendar recycle view
Tonic Sol-fa Screen Added
Merge Pull
Yes colors
Before leasing out to testers
Working but unformated table
Added Seperators but we have a glithchchchc
Tonic sol-fa nice, dots left, and some extras :)))
Just a nice commit on a good friday.
Just a quickie
I dont know what im committing...

What baffles me is how despite being on version 3 of Swift, Apple still havent updated Xcodes refactoring tools to support it. All I want to do is rename a variable or function but oh no. "Xcode can only refactor C or Objective-C code". Yet they are plowing on with new features in other areas like the interface builder but completely ignoring the tools that make IDEs useful.

This year I'm asked to teach Python with a GUI, but I've never used a graphic interface with Python. The chosen GUI must:
- Have an IDE, a sort of "drag and drop builder"
- Be capable of building software with forms, menus and multiple windows.
- Work with Windows 7 at least.
- Work with Python 3+

Any suggestions?

So far I tried:

- Tkinter: comes with the language (point in favor), but wasn't really able to make it work. Has no proper IDE, tried to use a builder called PAGE but doesn't seem to work.

- WxPython: didn't really play much with it. I've read some articles, but that's all.

- Qt: used several years ago with Ruby. Has an IDE (point in favor), but never tried with Python. This is my winner so far, the one big problem being the amount of stuff to install to properly work.

Worked all my life in C++/Java and for the first time in Android, finished the android app (ffs that's one messy framework)... now they give me an old macbook and send me into swift/xcode, I have been trying to connect two text fields and a button for 90 minutes, getting furious knowing I have to finish this app all over again for ios, please tell me how fucked am I? Is it better or worse than Android when it comes to a learning curve? I've googled this and usually it's fanboys fanboying, has anyone done both and has any advice?

P.S. I'm young and still tend to learn fast, but man this is really giving me shit, especially the IDE and interface builder which I despise as a concept, rather just write code instead of dragging and dropping...

Layout constraints sometimes can be such a pain in the arse. Very frustrating.

Are there out solutions to create cross-platform GUIs withing a GUI (like Blend in Visual Studio) which does interface with C++?(leave out Qt)

Searching the web I only found GUI libraries in C++, which are big turnoff for designers.

Further research leaded me to a viable solution that seems haven't been built yet anywhere, I'm taking about OpenGL\Vulkan as the engine for a cross-platform GUI builder within a GUI.

i always get sucked into this "cute code" hell whenever i am working with a b2c codebase, and especially with kotlin code.

here's a scenario:

task : build a debounce logic for an input view where each user input is currently triggerring an api call.

my steps
1. read what debouncing is.
2. see if any code is available on the internet
=> found a code piece on the internet with some level of abstraction ( basically a simple final class that implements the input event callback and encapsulates the debounce logic)
3) copy it, run it , it wokrs

------

for any sane coder, these steps are hardly 10-30 mins and they can move on with life. but its your truly that made this task into a 6hour research only to come up at similar solution. my curiosity led me to stupid places

1) why this class is final? what if someone else wanna use it but with a different behaviour? lets try open(non final class) .

2) why even use a class? it extends an interface, lets try to wrap the logic in interface itself (kotlin supports interfaces that don't require implementation)

3) umm , the interface works but it looks ugly, with all its global overridden variables. what about we make it extension?

4) yeah the extension approach is also not very good, lets go back to open class.

5) but extend is super nice to look! lets keep the extension and open class too

6) can we optimise the implementation? why it uses an additional handler? what if we provided everything in constructor? how about builder pattern?

FUCK MY BRAIN! there are so much fucking options that i forgot that i spent 4 hours on this small thing

the simplest approach would have been tk just shove all the listeners and everything in activity and forget about it :/

senior devs on this platform, how do you stop yourself from adding every concept that you know into the smallest possible task?