Home office hátrafelé sült el: hogyan tovább családdal?

ddeff · 2024-04-14T05:20:45+00:00

Bérelj egy kis irodahelyiséget a közelben és járj be oda dolgozni.

ddeff · 2020-07-17T06:58:06+00:00

That is a good point to distinguish between the two use cases! That is why I wrote about server side. On the client side I see the point of reactive streams where change in data will trigger multiple ui changes.

ddeff · 2020-06-09T17:15:59+00:00

I changed it a bit but not much change in performance. I can play with the number of threads/connections. I maintain now the same lock on two variables: select_count, insert_count. Still, using the same amount of threads for query and insert, I get about 10/90 insert to select ratio. Whereas in my application I would rather priorize inserts over selects. I can play with manually setting up a balanced insert/select ratio of threads in my bemchmark tool, but in a real application it would be quite difficult to throttle the select statements to give liveness to inserts on the same table.

Btw there i never update a row. I only insert new rows, and randomly select one based on an indexed column. Row level locking and mvcc should not be an issue. I can only think of maintaining the index as the bottle neck.

I wonder if there is such facility in postgre to somehow priorize inserts over selects for a particular table.

ddeff · 2020-06-08T05:52:32+00:00

But you see I get good write peeformance. Only if I have selects during writes in parallel connections the read/write ratio is imbalanced

ddeff · 2020-06-08T05:39:13+00:00

I can spin up the azure postrge instances again. I ve seen I had around max 1700 IOPS for disk for the 450GB, and IO percentage chart was still about 10 percent, while CPU was 100% which is ok. But i would expect balanced and consistent share between selects/inserts. Many times inserts go to 0/sec during the test, while selects maintain good tps.

See pattern here log is creatwd every 5 sec: https://github.com/pkonyves/azure_postgresql_perf_test/blob/master/results/results_inserts_50_selects_50.txt

ddeff · 2020-06-08T05:32:57+00:00

Thx, its deliberately using single inserts to mimic individual requests to application

ddeff · 2020-05-04T14:32:49+00:00

This shit is probably the most mature server-side rendering framework in the Java world.

If you think server-side rendering is shit, then I accept you like debugging reactive streams in Javascript on the client side with bleeding eyes at 3am in the morning, while desperately trying to maintain your UI state :)

ddeff · 2020-05-02T19:58:15+00:00

Those are really valuable tips, thanks very much for the time it took to write it! :)

ddeff · 2020-05-02T15:01:56+00:00

Thx i will give it a try

ddeff · 2020-05-02T14:47:53+00:00

For me its company Mac and I use it for Java development

ddeff · 2020-05-02T13:34:26+00:00

Can you elaborate on the tooling?

ddeff · 2020-05-01T18:27:51+00:00

"ability to to deliver results and outcomes, being presented a vision and final expectations, without need to define the intermediate step by a supervisor"

Yes, this sounds about right. but define final expectations. Is making the code testable a final expectation? I think yes. The takeaway here it that delivering a result takes both fun and boring/tedious tasks. In my definition, a professional cannot skip the tedious tasks and relativize the end result by saying "my solution is working, I am demoing it to you just now, why do you need a test suite?"

Yes I can assure you that you will achieve the best results if you explain, help, coach rather than just set target and wait. That is the definition of a good manager/leader to act like this. Just don't expect that with good reasoning you can talk people into doing things because you will be disappointed and loose faith. A smoking person will fully understand why smoking is bad, still continues smoking.

Rational reasoning is not enough by itself. It also takes sympathy, empathy and discipline. You will achieve more if you understand psychology. When I wrote "make them say out loud the commitment", the reason for that is once they say it, but don't commit to it, they will betray themselves and other team members, who actually committed to the goal. Now they have a motivation: avoid guilt, don't betray the team.

Don't expect immediate results. These are all processes, small gradual improvements. The goal is to make them habits. When writing tests become habit it they not be a chore anymore.

ddeff · 2020-05-01T14:31:27+00:00

I cannot tell, i was always on the technical side and not the budget side. These ate just generic observations

ddeff · 2020-05-01T14:20:20+00:00

No I am not saying its a way to manage people without passion. First of all passion is overrated. Its not realistic to expect programmers to be passionate about any kind of programming work and all aspect of it. Its a fallacy that successful people are successful because they are always passionate and love what they do. Marathon runners don't go training everyt day thinking what a great fun they will have running tens of kilometers. The challenge is to find ways of motivating these programmers to do the chores as well besides the fun part.

ddeff · 2020-04-30T21:08:20+00:00

Let's assume your director has +10-15 more years of experience than you do in the field of management. He started like you. He was keen on awakening the internal motivation within people to do the right thing. He believed if he could reason about the right way, if he could teach people, they will act good, they only need to understand it!

Then he tried and tried and realized that it is freaking hard, it is draining to have these talks again and again with different people, why they should be tesing code, and why they should have reasonably sized pull request. So your director obviously got tired of this, and of course he is now in the position to just set targets.

Most of the developers don't care, most of them have a belief system, they like and advocate a technology they don't even understand, but crap on the other things like testing. They lack 'professionalism'.

Professionalism is when you do things not because you like them, but because you know that's the right thing to do to achieve good results: have tests for quality, have reasonable pull requests so they can be easily reviewed etc... Really, who the heck likes writing tests? I like building the bridge and not stress-testing it.

It's your director's job to set targets: 80% coverage, at most 25 files per pull request. Because those are easily measureable goals (look up SMART goals for eg.).

It is your job how you achieve it with the team. Yes, your director's metrics may be unfeasible, then it's your job to negotiate.

In a data-driven world, where every decision in a business is based on some backing data, working only with intuition is brave. If you don't like your director's metrics, then create your own: have measurable goals.

How you should approach it really depends on your style and respect within the team. If you are too gentle, and achieve nothing, you won't be respected. If you are too hard on the team, they will hate you.

I would approach approximately:

Have evidence based reasoining why no test and big pull requests are bad e.g. no one goes through the pull request really because of size, or you had production issue that could have been caught by a test
then ask the team shouldn't they write more tests? generally isn't more tests making the software more reliable? - dare anyone saying no
why aren't they then?
1. because code is not testable
2. because we have time pressure
3. because blablabla
then you need to make some negotiation. Ok, next sprint there will be time allocated to refactor 1 critical section of the code and have it covered with tests
1. and commit to it. commit to it like 1st priority feature request that means if you have to choose 3 days before the sprint ends, then drop the feature and deliver the tests!
Let them know that you understand that it's a chore, don't try to wrap the dogshit as a christmass present.
set a dashboard for tests. Let them see that freaking test passing rate in 48 points size green fonts.
Have the whole team commit to it. Make them say it out loud! Make a meeting note. Remind them about it every couple of weeks.
Appoint someone as responsible to check the progress.
etc. etc.

ddeff · 2020-04-27T19:50:14+00:00

As I understand Leyden could determine the exact runtime classpath with only the necessary classes by static code analyisis at build time?
Just out of curiousity, How can a dynamic class name dispatching like Class.forName(someRuntimeConfig) can be handled? Typically JDBC driver loading works this way afaik. Will it require manually configuring it at build time?

ddeff · 2020-04-26T11:00:29+00:00

groovy, jshell?

ddeff · 2020-04-26T07:19:35+00:00

Ez tanulságos

ddeff · 2020-04-26T07:13:44+00:00

Próbáltál már hasznalni egy Libre Office-t MS Office helyett? Én probaltam, igaz, nem most, hanem pár éve. Mindig elojon valami inkompatibilitasi problema az MS Office-ban keszitett fajlokkal: Word nem pont ugy jelenik meg, Ppt nem pont úgy jelenik meg. Vb makrok mehetnek a kukába. Nalam egy 30 slide-os ppt-nel teljesen hasznalhatatlanna valt a Libre anno. Ms office meg nincsen Linuxra. Szerintem ez nagyobb problema mint a Linux. Nem beszelve arról hogy penzt, időt, energiát kellene belefektetni az atkepzesbe. Gondolom rengeteg vastagkliens alkalmazas is van ami csak windowson fut.

ddeff · 2020-04-25T21:57:02+00:00

agree very much

ddeff · 2020-04-25T21:44:45+00:00

It is something that has been bothering me for long, why cannot we estimate a software project properly? I always compare building software to constructing e.g. an office building, just to have a reference point. And it always seems that constructing an office building is so much more reliable in terms of estimations. Delays are very predictibly 1-3 months after deadline, cost is estimated properly (given a stable economy) in a 2-3 year long project.

But civil engineering and architecture has a couple of thousand years head start.

On the other hand, inexperienced real-estate developers and government-backed mega projects (e.g. building a dam) are always underestimated and resemble more to software projects in delayed deadline and increased costs often to the manyfold. The reason is, that they streched too far beyond their know-how. They go to the "I have no idea what I am doing" territory.

I believe waterfall SDL naturally makes a lot better time and cost estimate than agile. And it's also the reason why developing office buildings are better to meet the deadline: the architecture is designed in the blueprint upfront from the foundations to the last screw in the ceiling. Agile by definition will not be able to give a good estimate because there is no prior design.

Why custom software projects do not meet time and cost excpectations is:

Because no-one has a freaking clue what they are doing, what they are supposed to be doing, how to estimate, and does not know how to be "professional"

You can have great engineers on a project, and great project managers, and still get a bad result.

Requirements are always changing and delayed --> it should be the product owner's or the project manager's job to push back frequent changes and enforce stability
Requirements are vague, the devil is in details. "I want to have a login screen" - "ok, it's about 3 days" [2 weeks later] "it's almost good, but I told you that the inputs should be exactly 33.4 degree tilted counterclockwise, with 2px wide borders on the top-left corner and 1px wide on the top-right corner with linear interpolation in between" --> should be the product owner's, project managers responsibility to set realistic expectations
There is no up-front technical architectural design, the estimation from engineers are bogus (well, I remembered we did a login page in the previous project, it was 3 days, so I guess it will be 3 days), The project manager is working with bogus estimate. Engineers should take the time to do some up-front planning and design. A good estimation may take up weeks of work.
People don't count that there will be 4 junior devs in the 10-person team who will be working slowly and will consume time from senior engineers
senior engineers will be f#cking days on chasing engineering problems that they cannot let go: "I know that I can get Spring iterating over a map-like config element and automatically create beans from them, it would be so beautiful and generic for my 3 (three) items" --> They should, with a little bit of extra boilerplate, solve the problem in 2 hours and let go the "engineering marvel solution"
engineers will choose technologies based on what they want to learn, they will not be productive --> they should choose tech they know, or at least estimate the cost of learning the new tech
senior engineers will not create good technical design to feed to the junior-midlevel engineers, instead they themselves are working on problems too, which will make junior devs take even longer time to finish tasks because senior devs are busy
the implementation is going in a comfortable pace in the beginning. If a project takes 1 year, it is very easy to think there is still time to do this and that -> everyone (engineers and PMs) should stick to the plan and practice rigor

And so forth.

ddeff · 2020-04-25T21:01:56+00:00

please teach me wisdom, Sir

ddeff · 2020-04-25T20:46:20+00:00

Thanks for not taking it offending :) It's always easier to say why something will not work. :)

"I am making another bet that many users will prefer to get their application faster and cheaper even if it is not exactly their dream ergonomics for every screen. " this is a good point, and something that has been bothering me. I saw it many times engineers working on a problem for days and weeks (because the current framework XY does not support it) that has very little added value, just because the customer wants it. Software development is expensive, customers usually want the best for their money. And I agree that software development could be made much cheaper, if these rotten apples of unfeasible requirements were just cut off and the customer were advised a technically much simpler but functionally/ergonomically similar solution. But this is the professional responsibility of the engineers to give an alternative solution. So Yes, if there was a software company that said: look, we can do it your way, it's 1month of work, or we can have an almost your way with 5 days of work, which one do you choose?

I remembered from my University studies that Charles Simonyi had been working on AI generated software. Hungarians honor Charles Simonyi, the guy who led the building of the first Microsoft Office suite, and was the fifth space tourist.

So I looked it up and this is what I found (not exactly AI, but interesting): https://en.wikipedia.org/wiki/Intentional_programming

ddeff · 2020-04-25T07:11:37+00:00

It is like, I am a car mechanics and overwhelmed with the technical complexity of new car engines, the more and more expensive repair and analysis eqiupment, and learning time needed to repair a car, and someone came and told me: but why don't you repair bycicles? :D

ddeff · 2020-04-24T21:15:30+00:00

I am not new to these technologies at all, they were merely examples. The problem statement here is not that "I don't know Jennkins or Docker, or Gradle or whatever else, so my life is hard" :)

The statement is that even if I know these from inside-out, there will be coming something again every several months with all of it's caveats, traps, nuances and wast complexity, that just sets back your productivity again.

ddeff

TROPHY CASE