189 karma · joined June 26, 2013
My opinion is that QML not going to supersede web tech any time soon. As broken as CSS is, it is here to stay for the a while yet. The tooling for QML isn't great. You're heavily relying on QT Creator etc and the licensing around all that stuff. The exact opposite of FOSS that the web embraces.
Also FWIW, I know it's a holy issue but when you copy lines round in python etc you ARE having to add and remove those extra bits of syntax except they're invisible, they're spaces/tabs (don't even). Any sane person would have to have white space visibility turned on in their editor so would just be looking at cruft anyways.
Then requirements start coming in, the stakeholders, the politics. The multi faceted organizations, the disparate teams with never ending edge cases.
3 years later when it's past phase 2 and creaking at the seams, along comes the next upstart... DJango! Which idiot picked that?!!! Me n my friends could....
I find myself more energized getting straight to work after a run.
Hope you work it out
Sometimes you do a few more web calls than you might otherwise. If you can get away with it then great! Because the benefits are plenty
Hell! Even just having the uri of where the resource came from is useful enough. That's before you've introduced related resources.
One time I was able to go back weeks to fetch some code I'd long since deleted and was nowhere to be found in git.
After adding the clang_64/bin dir on the $PATH I too am getting 'ld: framework not found QtCore'.
Anyone able to suggest where I'm going wrong?
This outputs artifacts to a sonatype nexus repo. From there, the binary can be promoted either automatically or manually to various environments.
It breaks Gitlabs rules of CI modifying the repo (with no explanation) but it allows any developer with any level of experience to easily release the product
There isn't one size fits all, different teams develop at different rates because of ability, requirements, deadlines, culture.
Just keep it simple stupid! Why have a separate branch for tags? Or hot fixes even ?
I'd be interested to know if you're running rust embedded and if so how easy it is to get started.
A few years ago it would have a been a nice to have. Now it's actually suspicious if they haven't dabbled!
It's ballsy to write a blog asking questions about docker.
I'm hoping a business plan will form when we follow the good peoples advice in this thread.
Doing a plan at this stage feels a bit like waterfall to me. I realise you can't get far without one but sitting down and writing one before we've established the pain points, opportunities & demands feels too early.
Maybe I'm just naive
It is for this reason we set ourselves a mini goal of a prototype with cut down features.
Also there’s a difference between an entire companies code in one VCS and a product with many modules.
I’ve had experience with the latter and can tell you some of the pro’s:
1. A single version for your product. This helps communications with QA, clients and managers. And communication is the game we are in whether we like it or not
2. Reduced friction in developing features that cut across modules. Lets say I need to add a column to a database and then expose in the Ui. update the sql, added the field in a webservice, make the necessary adjustments in the UI, write the tests all on the same commit.
3. Increased collaboration. Quite often invisible lines are drawn on development teams where devs are feel they are unable to modify a module because they didn’t write it, they don’t understand it or they just feel that its not a part of their job. With everything in one repo this reduces the barrier to entry
Its not a free lunch though. Like you mention build times go up For one.
I’m a jvm dev and I find gradle extremely useful in this regard. Features like Muti project builds and concurrent builds are invaluable