287 stories
·
0 followers

Rowhammer-like attack on SSDs can provide root privileges to attacker

1 Share
Comments
Read the whole story
karlosmid
1 hour ago
reply
Zagreb
Share this story
Delete

Highlights on "quality," and Deming's work as it applies to software development

1 Share

Comments

Read the whole story
karlosmid
17 hours ago
reply
Zagreb
Share this story
Delete

Do you need a mentor?

1 Share

– All code I write is… bullshit?
– Yes, it is.

(conversation between 2 developers somewhere in the Middle-earth)

The cruel truth is that the dialogue above is valid for most of the people involved in programming to some extent (developers, automation guys, DevOps, etc.). It sounds crazy because you like coding, you do our best, always improving skills, extending knowledge, digging, digging, digging…

How come?

It could be because of different reasons. I was thinking – how can any of us understand that our code isn’t good enough? How can we accept that our code is far from ideal, sometimes even bullshit, as mentioned? First of all, when we learn-by-doing something, our brain is limited by what we’ve learned already. It’s in the cage of current experience and we don’t know sometimes (actually, quite often) how can we do better or what can be improved.

That’s where mentors come into play. The main role of a mentor is to lead you. Just for preventing misunderstanding, a mentor is not a teacher or a lecturer, or your warden. He is a guy who can and who is allowed to tell that your code is bullshit. Of course, there is nothing offensive in such situation, a mentor sees how things are going from the different point of view. And this vision together with mentor’s experience helps him to give tips of advice which are the most relevant for your case.

Examples?

I don’t get tired of repeating: nothing is perfect, neither is software, neither are people who create it. For instance, I wrote code which was clean and readable, well designed and easy to maintain from my point of view. But when I sent it for the developer’s review, I was surprised how much my “perfect” code could be improved. Simple example but after that, I understood how valuable a feedback from someone who is level up from you can be.

No doubts, sometimes you have a look at the old code and see obvious problems, especially when you haven’t seen it for several months or so. And you think: “Did I create it? How come?”. That’s because you’re getting better every f**cking line of code you write, if this line has a background underneath. When I say “background”, I mean dozens of read StackOverflow questions & answers, Javadoc (or any other -doc from the other languages) and articles that we learned and analyzed for writing that single but important line. This is a mostly self-organised process but a mentor plays a vital role in it by adjusting, leading but not forcing.

What a beautiful world!

In order to understand how else a mentor can be useful, let’s imagine for a moment that you have the superpower to create a new world, for example, a fantasy world, but you have no or very basic skills in worlds design. Are you gonna fail? Most likely, at least you will not be able to build a perfect word where everybody’s happy and everything goes well. The very first version of such word will be raw and slack-baked and have lots areas for improvements. Yeah, ..it happens! The second one may be better, if you don’t make too many fixes by guess. And so on, and so far.

It’s okay, if you play with a fictional world. But what if you’re almighty and a single wrong decision can affect millions of people? In this case, a mentor can help by, for example, explaining best practices in building worlds, pointing at pitfalls to avoid, saying which component can be added to the map. Such a great architect. No, such The Great Architect.

Our automation framework is a world. A world that we build sometimes without complete understanding how it should work and grow. When the time comes, we need to change it but changes can be very painful and expensive (remember the previous paragraph?). However, we’re ready to do these changes because it’s our framework, our baby. But it will become very difficult to maintain eventually.

Conclusions

A mentor can help you to design test frameworks which don’t trigger a headache neither for you nor for their users. A mentor can emphasize tough areas where you can add flexibility for future. A mentor can advise design patterns which will make your code readable and easy to maintain. A mentor can do a lot for you. Just ask

The post Do you need a mentor? appeared first on YOUR TEST AUTOMATION HUB.

Read the whole story
karlosmid
17 hours ago
reply
Zagreb
Share this story
Delete

Patterns in AST Board Candidate Responses

1 Share
In my last post I announced my running for the Board of Directors for the Association for Software Testing. Voting for the board starts next week (so watch for AST’s email) but the list of AST Board Nominees now contains each persons Candidate Questionnaire replies, including my own. After the replies were posted, I took […]
Read the whole story
karlosmid
17 hours ago
reply
Zagreb
Share this story
Delete

See You Triangulater

1 Share

Perhaps it's true that there's nothing new under the sun, but that doesn't mean that what's already known is necessarily uninteresting. Here's a quick example: I was recently reflecting on how talking to multiple people about their perspectives, finding data from several independent sources, or asking the same question in different ways felt analogous to a technique from surveying, triangulation.

Triangulation is an ancient but still widespread method of mapping a landscape in which a network of points are plotted in relationship to one another, with each point always connected to two others, making triangles. Building one triangle against the next, and the next, and the next allows the whole space under consideration to be covered.

I'm nowhere near the first here, though, as a quick search established:
In the social sciences, triangle is often used to indicate that two (or more) methods are used in a study in order to check the results of one and the same subject ... By combining multiple observers, theories, methods, and empirical materials, researchers can hope to overcome the weakness or intrinsic biases and the problems that come from single method, single-observer and single-theory studies.
So what's my point? Testing frequently involves collations, connections, and comparisons. Triangulation is an interesting model of those activities to consider, for me, right now, even there's likely no solar system in which it's a novel one.
Image: https://flic.kr/p/5p4mBt
Read the whole story
karlosmid
17 hours ago
reply
Zagreb
Share this story
Delete

תזכורת על חשיבות התזמון Reminder about timely feedback

1 Share
אחד הדברים שיוצא לשמוע לא מעט על בדיקות תוכנה הוא שמדובר בעסק של אספקת מידע - והדגש הוא תמיד על אספקת מידע מועיל בזמן. 
אבל, מה לעשות - זה לא תמיד מצליח. אתמול,ביום חמישי, למשל, עברתי על מסמך שנשלח אלי לסקירה, ובעקבות ההערות שלי אנחנו רוצים לשנות לגמרי את מבנה המסמך. אבל - המסמך הזה יוצג ביום ראשון לאוסף של אנשים שקשה למדי לכנס בחדר אחד, וחלק מהשינויים הדרושים ייקחו קצת יותר מאשר יום (זה לא מסמך קצר, ומי שכותב אותו הוא קצת כמוני - לוקח לנו נצח לכתוב משפט וחצי). אז מה עושים? "טוב, נו, חבל. אולי נתקן את זה אחר כך, אבל בינתיים נציג אותו כמו שהוא יחד עם כמה מהתיקונים הקטנים יותר שכן אפשר להכניס". שנינו מסכימים שהיה עדיף לשנות את הפורמט, שנינו מסכימים שעדיף להציג את המסמך הנוכחי מאשר לנסות לאסוף את כולם באותו חדר שוב, שנינו קצת מבואסים מזה. 
אילו הייתי מגיע לפני יומיים עם התובנות האלה (מה שהיה אפשרי, אילו הייתי מגיע לקרוא את המסמך קודם) - שנינו היינו מרוצים יותר. 
אבל, החלק שקצת חבל לי הוא שאני לא חושב שיש הרבה מה ללמוד מהמקרה הזה - בהינתן מצב דומה, כנראה שהייתי חוזר על ההתנהגות הנוכחית ומגיע לקרוא את המסמך יחסית מאוחר. למה? כי היו לי משימות דחופות יותר, וכי לא ציפיתי שיהיו לי הערות שינוי עד כדי כך מרחיקות לכת.  יכול להיות שברפרוף מהיר על המסמך יכולתי לתת משוב ראשוני, אבל במקרה הזה לקח לי בערך חצי שעה להבין שמשהו לא בסדר, אז לא בטוח עד כמה רפרוף היה עוזר. 
אבל נו, זה החלק העצוב של יוריסטיקות - הן נכשלות לפעמים. 

------------------------------------------------------------------------------------------
One of the things commonly said about software testing is that it is the business of providing information - focusing on timely & relevant information. 
However, this doesn't always work out well. Yesterday, in Thursday, I spent several hours reviewing a document sent to me by a colleague. One of my comments was "the scope of this document is wrong" and another one was "I'm missing some sections about this, this and that". Knowing that these changes mean quite a bit of work I hopped over to the room next door and had a little chat with the author. We both agreed that the changes would make the document better, but a review meeting is already set to Sunday, and it isn't easy to get the relevant people in one room, so moving the meeting is quite expensive, even ignoring the other stress factor that want this review done (some very pushy project managers and possibly a miscommunication with some customers). Making those changes would require a bit more than half a day (Weekend in Israel is Friday & Saturday)  and we both agree that presenting the document as is would be better to presenting a better version of it later. Still, now both of us are bummed because we know this could have been better had I come up with this feedback a couple of days earlier. 
The sad part is that I don't think there's much to learn here. It's a reminder of why timely feedback is important, but given a similar situation I would probably behave in a similar manner, postponing the review to deal with more urgent (and more important) tasks. Most of the times, my comments might be numerous and require some work to fix, but it is usually less than half a day.  Maybe, had I skimmed the document... but it took me about half an hour to realize that the structure of the document was wrong, so I think it wouldn't have helped. All in all, that's the meaning of risk - something might go wrong, and I have accepted this risk. 
Ah, well, that's the sad part about heuristics (I used "if it was urgent and important, someone would be nagging me" heuristic) - they sometime fail. 
Read the whole story
karlosmid
17 hours ago
reply
Zagreb
Share this story
Delete
Next Page of Stories