Friday, October 4, 2019

Some CSS basic standard

Standards CSS - LESS


Règles de déclaration des variables
  • Utilisez pas le namespace du core pour nommer une variable. Pour des composants au niveau des outil, ajoutez le namespace correspondant à l'outil.
  • Les variables de contexte du composant sont déclaré avec le préfixe de contexte suivi de deux traits d'union.
  • Propriétés toujours en fin de déclaration
  • Les déclarations de variables suivent une imbrication en cascade. Seuls le nom du composant et la propriété CSS sont requis.
Exemple :
// CORE component variable name
[CONTEXT]--[COMPONENT]-[EXTENTION]-[PSEUDO CLASS]-[PROPERTY]
@reverse--componente-name-extention-property

// TOOL component variable name
[CONTEXT]--[TOOLNAMESPACE]-[COMPONENT]-[EXTENTION]-[PSEUDO CLASS]-[PROPERTY]
@reverse--adb-memberdataupdate-componente-name-extention-property

Règles de déclaration du composant
  • Le nom du composant doit être unique. Assurez vous de faire un recherche sur les fichiers LESS de la solution avant de le nommer.
  • Utilisez de la classe à la place du id pour la identité du composant.
  • Fournissez toujours des renseignement sur les composants, surtout de particularités nécessaires à la compréhension, qui ne sont pas claire sur le code.
  • Les déclarations doivent être toujours dans le namespace #adb-webtools-container.
  • Déclarez pas le margin au composant pour ajouter une distance distance vers son parent ou ses fréres doit être, ça doit être déclaré au contexte.

Syntaxe du code du composant
//*****************************************************/
//  Component name
//*****************************************************/
/*
    Component description
    ...
*/
@my-component-color: 1px solid @color-g6;
@my-component-border: 1px solid @color-g6;
@my-component-active-color: @color-acive;
@reverse--my-component-color: @color-g7;
#adb-webtools-container {

    // Component
    .my-component {
        color: @my-component-color;
        border: @my-component-border;

        // Component elements
        .my-component-title {
            ...
            
        }

        // Component extension/states
        &.my-component-active {
            color: @my-component-active-color;
        }
        &.my-component-medium {
            ...
        }
    }

    // Contexts
    .reverse{
        .my-component {
            color: @reverse--my-component-color;
        }
    }

    // Print mode
    &.adb-webtools-print {
        .my-component {
            color: @color-black;
        }
   }

    // Browser support
    &.adb-webtools-browser-internet-explorer {
        .my-component {
            // Fix
        }
    }
}



LESS client

Variables
Changer les variables toujours au début du fichier less.
@color-primary: #DDD;
Pour de variables spécifiques à l'outil utilisez le namespace de l’outil comme préfix.
Ces variables doivent être déclarées dans le fichier Less core de l’outil avec un valeur par default.
@memberdataupdate-section-boder-color : @color-primary;
Utilisez toujours de variable du core pour des propretés standardisées.
color: @color-primary;
font-size: @font-size-sm-a;
@media @media-sm-max-width{
    padding: @layoutHorizontalSpacing;
}
Namespaces, class, id, print
Les déclarations des classes et des ids doivent être toujours dans le namespace #adb-webtools-container.
@color-primary: #DDD;

#adb-webtools-container {
    
    // CORE prefix adb-webtools
    // Overridez JAMAIS une class or id du core. Discutez avec le responsable au besoin.
    .adb-webtools-header{
       color: red;
    }

    // NAMESPACE
    // Utilisez le namespace de outil pour déclarer des classes et id spécifiques à l'outil.
    // Jamais utiliser le namespace du core adb-webtools pour ça.
    // Utilisez des classe pour de composant au section générique.
    .adb-memberdataupdate-my-component {
        color: @color-primary;
        font-size: @font-size-sm-a;
        @media @media-sm-max-width{
              padding: @layoutHorizontalSpacing;
        }
    }
    
    // CONTEXTE
    // Utilisez des id de section pour donne un contexte au changement.
    #adb-memberdataupdate-section-x {
        .adb-memberdataupdate-my-component {
            color: @color-secondary;
        }
    }

    // PRINT MODE
    // Utilisez la classe adb-webtools-print liée #adb-webtools-container 
    // pour déclarer le changement de style au mode print/pdf.
    &.adb-webtools-print{
        .adb-memberdataupdate-my-component {
            margin: 0; 
        }
   }
}

Tuesday, March 5, 2019

Bits from the book "97 Things evey project manager should know" from O'reilly


This is a list of some of the subjects I felt more close to my vision of project management.
Of course it is not an extensive list and tried to put together a small one. So there might be other gems not being considered in this list. My suggestion would be to read book, it's not that long of a read and should be something you can finish on a week of late night/before bed reading session. Here I only put some of the phrases that catched my attention and not the whole piece.

1. Developer productivity: skilled versus Average. Neal Ford. P. 26.

"Let's debunk some of the myths about developer skills for project managers who have been assigned for the first time to software projects. Understand  that really good software developers are much more productive than average ones...The point is, a skilled programmer isn't  just a little better than an average one; the difference is huge."


2. Managing  Human Factors in IT project management. James Graham. P. 48

"As software project managers, we obsess over the scheudle details. We huddle with our teammates to try to anticipate risk factors that could derail our projects. We crunch numbers to see if we can squeeze the project deliverables out of the allocated budget. But we tend to overlook, or ignore, the most prevalent cause of project failure: the human factor".



Monday, August 27, 2018

Nsubstitute basic test & TDD note

I have been working on creating unit tests and to some extent also doing some TDD. I think TDD at the beginning when you come from a background of classical development of develop-first test-later, is a change that might not come so naturally the first time you tried. However the more you try to understand the test driven model the more you actually realize how you can benefit from thinking on what is the purpouse of you code and the how to fix it. Refactoring is a big part of TDD and something I think I am used to but never thought of it like a natural process to deliver a more robust design based on testing while coding. So here is a small example on nsubstitute:


Here we have the beginning of the class to test a cube iterator.  In the image below I created a class to fill the values on a setup mode to be called when the data is about to be treated([TestInitialize]).

The method Setup is where I am going to setup the mocking for my classes.









Finally I test my values on a Given-When-Should pattern so I know what I am passing what method/action I am invoking and what I expect as a result. Nsubstitute handles some easy  fluent methods.


Thursday, August 17, 2017

jquery event handling

Here is an example of basic event handling with JQUERY.. I know these days is probably not so relevant, but since there are still many legacy projects with jquery. All this from the linkedin learning center.



jQuery Event Handling


Thursday, January 26, 2017

Code Reviews

learning from "Code Reviews"


How to implement a good code review policy that actually provides value to the software process? Should everyone do a code review? should only be limited to senior programmers?

start by defining who will make the code review; you want to give your programmers the ability to learn from each other  and to actually improve the code or to at least be compliant the standards in place.

Monday, July 18, 2016

Programming opinions...

Here a copy of the list of 20 programming opinions from Programmer community Blog.

I pasted the ones I like the most but certainly the all deserve to be read.


1.

Programmers who don’t code in their spare time for fun will never become as good as those that do.

  I think even the smartest and most talented people will never become truly good programmers unless they treat it as more than a job. Meaning that they do little projects on the side, or just mess with lots of different languages and ideas in their spare time.
by rustyshelf


5.

“Googling it” is okay!

  Yes, I know it offends some people out there that their years of intense memorization and/or glorious stacks of programming books are starting to fall by the wayside to a resource that anyone can access within seconds, but you shouldn’t hold that against people that use it. Too often I hear googling answers to problems the result of criticism, and it really is without sense. First of all, it must be conceded that everyone needs materials to reference. You don’t know everything and you will need to look things up. Conceding that, does it really matter where you got the information? Does it matter if you looked it up in a book, looked it up on Google, or heard it from a talking frog that you hallucinated? No. A right answer is a right answer. What is important is that you understand the material, use it as the means to an end of a successful programming solution, and the client/your employer is happy with the results.
by PhoenixRedeemer

6.

Not all programmers are created equal.

  Quite often managers think that DeveloperA == DeveloperB simply because they have same level of experience and so on. In actual fact, the performance of one developer can be 10x or even 100x that of another. It’s politically risky to talk about it, but sometimes I feel like pointing out that, even though several team members may appear to be of equal skill, it’s not always the case. I have even seen cases where lead developers were ‘beyond hope’ and junior devs did all the actual work – I made sure they got the credit, though.
by Dmitri Nesteruk

17.

Software development is just a job.

 I enjoy software development a lot. I’ve written a blog for the last few years on the subject. I’ve spent enough time on here to have >5000 reputation points. And I work in a start-up doing typically 60 hour weeks for much less money than I could get as a contractor because the team is fantastic and the work is interesting. But in the grand scheme of things, it is just a job. It ranks in importance below many things such as family, my girlfriend, friends, happiness etc., and below other things I’d rather be doing if I had an unlimited supply of cash such as riding motorbikes, sailing yachts, or snowboarding. I think sometimes a lot of developers forget that developing is just something that allows us to have the more important things in life (and to have them by doing something we enjoy) rather than being the end goal in itself.
by Greg Beech




Programming opinions...

Here a copy of the list of 20 programming opinions from Programmer community Blog.

I pasted the ones I like the most but certainly the all deserve to be read.


1.

Programmers who don’t code in their spare time for fun will never become as good as those that do.

  I think even the smartest and most talented people will never become truly good programmers unless they treat it as more than a job. Meaning that they do little projects on the side, or just mess with lots of different languages and ideas in their spare time.
by rustyshelf


5.

“Googling it” is okay!

  Yes, I know it offends some people out there that their years of intense memorization and/or glorious stacks of programming books are starting to fall by the wayside to a resource that anyone can access within seconds, but you shouldn’t hold that against people that use it. Too often I hear googling answers to problems the result of criticism, and it really is without sense. First of all, it must be conceded that everyone needs materials to reference. You don’t know everything and you will need to look things up. Conceding that, does it really matter where you got the information? Does it matter if you looked it up in a book, looked it up on Google, or heard it from a talking frog that you hallucinated? No. A right answer is a right answer. What is important is that you understand the material, use it as the means to an end of a successful programming solution, and the client/your employer is happy with the results.
by PhoenixRedeemer

6.

Not all programmers are created equal.

  Quite often managers think that DeveloperA == DeveloperB simply because they have same level of experience and so on. In actual fact, the performance of one developer can be 10x or even 100x that of another. It’s politically risky to talk about it, but sometimes I feel like pointing out that, even though several team members may appear to be of equal skill, it’s not always the case. I have even seen cases where lead developers were ‘beyond hope’ and junior devs did all the actual work – I made sure they got the credit, though.
by Dmitri Nesteruk

17.

Software development is just a job.

 I enjoy software development a lot. I’ve written a blog for the last few years on the subject. I’ve spent enough time on here to have >5000 reputation points. And I work in a start-up doing typically 60 hour weeks for much less money than I could get as a contractor because the team is fantastic and the work is interesting. But in the grand scheme of things, it is just a job. It ranks in importance below many things such as family, my girlfriend, friends, happiness etc., and below other things I’d rather be doing if I had an unlimited supply of cash such as riding motorbikes, sailing yachts, or snowboarding. I think sometimes a lot of developers forget that developing is just something that allows us to have the more important things in life (and to have them by doing something we enjoy) rather than being the end goal in itself.
by Greg Beech