7
points
zffr
Joined 976 karma
- 2 points
- Just curious, why do you want to migrate from mongo (document database server) to sqlite (relational database library)?
That migration would be making two changes: document-based -> relational, and server -> library.
Have you considered migrating to Postgres instead? By using another DB server you won't need to change your application as much.
- I was with you until this part:
> Thus any attempt at estimates is as futile as gambling to win, tasks are only ever done when they're done, and "successful estimators" are kings of retconning.
> It's all make-believe.
Software estimates are not futile or make believe. They are useful even if they are not always precise. That’s why the industry continues to use them.
- I just tested this on my computer.
After all that you can build and run on a simulator1. Make a new Xcode iOS project and delete all files except for Info.plist 2. Remove all keys from Info.plist 3. In the build settings search for "storyboard" and remove all keys 4. Add yellow.asm to project 5. Link UIKit, and Foundation - > so it's almost certain that private APIs would get accessed
No it's not. Just like with ObjC or Swift, in ASM you have to be explicit about the APIs you want to call. I don't see how you would accidentally call a private API in ASM.
IMO the bigger risk is attempting to call a method that does not actually exist. ObjC or Swift would protect you from that, but ASM would not and may just crash at runtime.
- One challenge is that JSON is for data and HTML is for UI. When a client gets JSON it can transform the data to make it ready for the UI. With HTML, the client is locked into the UI chosen by the server.
What if the client wants to render the output of an API in different ways depending on what screen is visible? If the server API outputs JSON, this is trivial. If it outputs HTML the client is stuck into rendering what the server gives it.
- What I like about TUIs are that they are forced to be simple, and are forced to load all data at once. I don’t prefer interacting with an app in a terminal window, but I do prefer the kinds of apps that are built with these constraints in mind.
There’s nothing preventing web apps from being built this way, but they just often are not.
- Apple’s typical process for releasing public API involves dogfooding it internally first. Sometimes it will take years of internal use before Apple will release API publicly.
With something as large as TextKit, I would be extremely surprised if Apple did not get several of its apps to adopt the new API and use it for a few years before considering releasing it publicly.
- 4 points
- 2 points
- PDFs don’t always contain actual text. Sometimes they just contain instructions to draw the letters.
For that reason, IMO rendering a PDF page as an image is a very reasonable way to extract information out of it.
For the other formats you mentioned, I agree that it is probably better to parse the document instead.
- What do you think the bottleneck was in your search?
Was it finding openings, getting interviews, or passing those interviews?
In my niche I’m finding that there are very few opening in the city I live in, but that getting interviews might not be too hard. Not sure how easy it would be to pass those interviews.
With dynamically linked frameworks you bear the cost of the entire framework (and its dependencies) even if you just use a few functions.
iOS apps also need to include all localized assets in each app bundle.