About Learning New Frameworks…

About Learning New Frameworks…

Seeing as I am currently in the boat of being an old dog learning new tricks, it is worth mentioning part of a conversation I had with a recruiter yesterday. (It was a great conversation, BTW… a real conversation, with a real person, not just a recruiter running through a checklist of questions, although we did that part, too.)

But I raised my concern with her that I have whenever I talk to new companies about coding jobs, that my background doesn’t include much in the way of modern frameworks, and while I am learning on my own, I can only honestly apply to jobs who will accept someone being at a senior level while still needing a learning curve. And she pointed out, on behalf of the manager for this job, that they have the opinion that learning your first modern framework is the first step, and after that they all come easier.

That probably is true – I can say that choosing Laravel was not the same choice I would make for a scalable SaaS product, or a enterprise product, and I agree that I chose it because it has a simplicity to it, despite flaws that simplicity brings. (mostly in the ORM and data migrations) I do suspect,  even after having only been digging into it for a week, the similarities between it and any other MVC-based framework will ease the learning burden elsewhere. So it is possible that in working towards building my side projects up into something that can generate enough revenue to pay my bills, I might accidentally be improving my skills enough to pick up the other frameworks, and not even have to make those apologies anymore.

On that note, I coded very little yesterday. I spent more time thinking out the data integration between my old page and my new app. Which oddly had more quirks to it than I thought at first. At first glance, how hard can it be? Just push a chunk of image data from the page over, and work with it. But I checked my server capactiy — I’m currently sitting at about 5% of my monthly storage and bandwidth and rising. So if I launch new features, and store the images and PDFs, I could quickly need to upgrade my server, which could turn this into a money-losing effort. So I decided to just pass the raw data, not the binary files. Then I had to look field-by-field to decide what to pass in the POST, because while I can certainly read and re-process all the fields from the raw data, POSTing them lets me use them immediately in the UI during the sav process, as I prompt the user for more info. I also thought quite a bit about the use cases of anonymous users – the page won’t know if you are logged in, so the button to save will always be there. I would want it there anyway just to inform people the feature exists. Either way, I need to save the image data when you are anonymous… and hang on to it as you login or register so you don’t have to restart when you finish logging in. Cookies are too small. Local storage doesn’t work across subdomains, at least not without iframe hacks, and I do want to set this up as a subdomain off my main site. I need to look into how Laravel does session-level storage. If that isn’t an option, I may just have a queue of anonymously posted data, sandboxed off to the side of the public data, and match it up to logins as they happen.

For better or worse, I don’t like to make software design choices instantly. I can throw them up on a whiteboard instantly, but I find that if I let them percolate for a day in my head, I’ll think of better ways to do things, so over the course of a day or two, a feature I want to write will evolve on my whiteboard, and I’ll save coding time by letting it evolve before I sit down and code it.

In any case, that was yesterday. Tossing my POST/ Login / Register / Save flow up on a whiteboard so I see it as I wander around my house, and tweaking it over the course of the day. I’ll code it up today or Monday.

 

 

Comments are closed.