Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Some thoughts about time relations in app dev:
10% - minimal ui & coding main functions
10% - testing
10% - writing web api just for fun
70% - try to "design" an ui
Am I the only one having problems with ui?? 🤔3 -
Looking for a second opinion/validation.
*Me: “Perhaps this simple and concise way to ensure the user doesn’t lose their data before they leave the page that requires non-zero yet minimal input from the user. (Read: ya gotta push a save/submit button)”
*Everyone else: Let’s pretend to read the user’s mind and perform relatively complicated functions behind the scenes, of which the user will most likely be unaware, that will add an undetermined amount of complexity to the development because we think it’s “where things are going,” by saving the value of a certain HTML element as it loses focus.
Edit: this is an exclusively-internally used app.4 -
* Start maintaining/upgrading new project at work
* Read book on best practices for the framework
* quickly realise all the "don't do this" parts of the examples in the book is EXACTLY how everything in the project is done
* cry self to sleep -
To me this is one of the most interesting topics. I always dream about creating the perfect programming class (not aimed at absolute beginners though, in the end there should be some usable software artifact), because I had to teach myself at least half of the skills I need everyday.
The goal of the class, which has at least to be a semester long, is to be able to create industry-ready software projects with a distributed architecture (i.e. client-server).
The important thing is to have a central theme over the whole class. Which means you should go through the software lifecycle at least once.
Let's say the class consists of 10 Units à ~3 hours (with breaks ofc) and takes place once a week, because that is the absolute minimum time to enable the students to do their homework.
1. Project setup, explanation of the whole toolchain. Init repositories, create SSH keys for github/bitbucket, git crash course (provide a cheat sheet).
Create a hello world web app with $framework. Run the web server, let the students poke around with it. Let them push their projects to their repositories.
The remainder of the lesson is for Q&A, technical problems and so on.
Homework: Read the docs of $framework. Do some commits, just alter the HTML & CSS a bit, give them your personal touch.
For the homework, provide a $chat channel/forum/mailing list or whatever for questions where not only the the teacher should help, but also the students help each other.
2. Setup of CI/Build automation. This is one of the hardest parts for the teacher/uni because the university must provide the necessary hardware for it, which costs money. But the students faces when they see that a push to master automatically triggers a build and deploys it to the right place where they can reach it from the web is priceless.
This is one recurring point over the whole course, as there will be more software artifacts beside the web app, which need to be added to the build process. I do not want to go deeper here, whether you use Jenkins, or Travis or whatev and Ansible or Puppet or whatev for automation. You probably have some docker container set up for this, because this is a very tedious task for initial setup, probably way out of proportion. But in the end there needs to be a running web service for every student which they can reach over a personal URL. Depending on the students interest on the topic it may be also better to setup this already before the first class starts and only introduce them to all the concepts in a theory block and do some more coding in the second half.
Homework: Use $framework to extend your web app. Make it a bit more user interactive with buttons, forms or the like. As we still have no backend here, you can output to alert or something.
3. Create a minimal backend with $backendFramework. Only to have something which speaks with the frontend so you can create API calls going back and forth. Also create a DB, relational or not. Discuss DB schema/model and answer student questions.
Homework: Create a form which gets transformed into JSON and sent to the backend, backend stores the user information in the DB and should also provide a query to view the entry.
4. Introduce mobile apps. As it would probably too much to introduce them both to iOS and Android, something like React Native (or whatever the most popular platform-agnostic framework is then) may come in handy. Do the same as with the minimal web app and add the build artifacts to CI. Also talk about getting software to the app/play store (a common question) and signing apps.
Homework: Use the view API call from the backend to show the data on the mobile. Play around with the mobile project to display it in a nice way.
5. Introduction to refactoring (yes, really), if we are really talking about JS here, mention things like typescript, flow, elm, reason and everything with types which compiles to JS. Types make it so much easier to refactor growing codebases and imho everybody should use it.
Flowtype would make it probably easier to get gradually introduced in the already existing codebase (and it plays nice with react native) but I want to be abstract here, so that is just a suggestion (and 100% typed languages such as ELM or Reason have so much nicer errors).
Also discuss other helpful tools like linters, formatters.
Homework: Introduce types to all your API calls and some important functions.
6. Introduction to (unit) tests. Similar as above.
Homework: Write a unit test for your form.
(TBC)4 -
I'm still on a regular basis reminded of how I might be wrong despite the absolute certainty in how obviously wrong the other person is.
Lately I've been working on setting up this API with a fairly intricate database integration. One request can lead to multiple db calls if we're not careful, so we have been polishing up the implementation to guard against ddosing ourselves and dealing with thread-unsafe concurrency.
Someone on the team could happily report that they got rid of all async use so there should no longer be threading issues. "You mean it all runs sync now?" "I guess. It works at least".
I'm just internally pulling a surrender cobra. If this was pre-dev me I would have let him and everyone know what a stupidpants he is and that I thought he had some experience in api development. But let's not make an exception to the rule; I might be wrong. I mean I'm not, but let's pretend I could be. Let's pull down the changes and maybe set up a minimal example to demonstrate how this is a bad idea.
Funny story. He got rid of explicit calls to the database entirely. When resolving data, the query is instead constructed virtually and execution is deferred until the last step. Our functions are sync now because they don't call the database, and threading isn't an issue since there's only one call per request context.
Thank god I've learned to keep my mouth shut until I can prove with absolute conclusive certainty that they are wrong. Here's to another day of not making an ass of myself. -
I really hate working with learning management systems (LMS).
I make training simulations for retail companies and some of these have the worst, backwards LMS's out there.
The providers who install and manage these LMSs for the companies always insist we make our training run inside their own environment, but we can't since it's a 3D training made in Unity that doesn't run well in a browser.
Luckily some of these are fine to figure out. Just a few API calls here and there for authorization and reporting progress, but some are an absolute nightmare.
Just now one of the providers provided me with a 2000 page documentation of all the functions of the LMS's API that our customer is using. All I need are like 5 pages that explain what URL to call with what data and the responses, but now I'm stuck spending days trying to find the 0.5% of this documentation that I need to communicate with their API.
And of course, the documentation is vague as all hell. minimal descriptions of what each endpoint does. Subjects names are super vague, as in do I look for course progress or lesson completion state. What the heck is a Learning Event, is it relevant to me?
And the errors in this document, too.
Bullet-point lists with duplicate items.
language errors everywhere.
Property lists where they copy-pasted the description of properties.
An entire EMPTY chapter, literally a page with only the chapter's title.
I just can't stand how these providers barely seem to know anything about the API of the LMS's they provide to customers.
(for clarity, the LMS is produced by some big tech company, it's installed and maintained by some 3rd party which is our main line of communication when rolling out trainings to these).
It always goes like: "Hey, we want to use your training." "Oh, that's great, we have our own, simple LMS where you can view your employee's progress." "Nah, we want to use our backwards LMS. Here's a giant manual about it's API, go figure it out!"
And then I'm left here tearing my hair out trying to figure out which 3 calls I need to send their API from the tons of extra stuff it can do which is completely unnecessary and being unable to rely on the provider because they lack the knowledge and have such thick skulls about the implementation of the LMS itself that they also seems completely unwilling to help to begin with!
Just another day at the office. -
Be me.
Writing a java class for uni work, that'll eventually run on android.
I get kicks from making functions work using as few steps as possible, using minimal code.
Explain to someone how I'm doing it.
I learn that loops and the rest of it generate more code and take longer than unwrapping the loop and writing every case manually.
Shit ffs I spend hours making my code more concise :(
Then, I'm told the recursive method I'm using for checking for a win is too complicated, that I shouldn't start looking for a win from the last counter I placed, but should scan the WHOLE board for a win in every angle.
Eat my food, open my beer, pet my dog, trundle off back to work.
Top Tags
Weekly Rant
View