Seed oils also contain toxins that generate more toxins. They get stored as body fat that is hard to be used for energy by the body. That makes you hungry because you need more energy so you eat more.

Toxic chemicals in seed oils Can cause heart attacks, strokes, growth defects, and birth defects.

Inflammation worsens allergies.

Junk food relies on starches and seed oils. Low nutrient foods make you fat because they are empty calories and even though you eat a lot your body is still hungry because it needs more nutrients.

Solution: eat more traditional fats like butter, olive oil, meat fats, avocado. Eat free-range dairy and meat. Minimize processed foods and lower starchy foods like potatoes, pasta, rice. Eat more veggies. Get 30 minutes of direct sunlight and supplement for vitamin D.

Disclaimer: all of this is my summary of what i read in a book and I’m no expert

https://twitter.com/GorkaCesium

I’ve tried custom blogs, LinkedIn posts, Substack, Twitter threads, dev.to and a few others. But now I come back here.

Although

I don’t like to read here because it feels like most blog posts optimize for revenue. I won’t mirror that. I want to write for the joy of writing.

https://twitter.com/GorkaCesium

In Brezza Screens Systems we use custom software to generate quote estimates of our window screens (mosquiteros). This has enabled us to serve much more customers with increased quality standards and reliability.

Previously, when a customer would ask how much does a Window Screen costs, we would use Excel to quote an estimate. That process was slow and required slow thinking, meaning that it required high level of focus to avoid making any mistake. Even though Excel is a powerful app, it is very easy to accidentally mess up a formula. Additionally, there is a potential risk when copying an existing Excel sheet to reuse it for another customer.

Thanks for reading Gorka’s thoughts! Subscribe for free to receive new posts and support my work.

Case: Esperto Window Screen

In this case there is a group of formulas to calculate the amount and length of threads that we should consider in our model Esperto Window Screen

Esperto Window Net

Example of XLS formula to calculate strings

These are the formulas for the length each of the 5 threads.

Example of how to understand a messy spreadsheet formula

In this case the formula is hard to read because it has a lot of conditionals and it is all in one line.

Formatting the formula allows an easier understanding. I use VSCode for that. I also replace the cell numbers with variable names. In this case I replaced `I4` for `height`.

Then I flatten the structure so it is easier to read.

Now it is easier to see how many threads should there be for each threshold of height size. Finally I rewrite this formula in Rescript and I plug it into our quote estimator app to have that logic in our pricing calculations.

This way we have the logic in an app that can display only the details that the user needs to make a quote. The calculation logic is protected from any human error from the user by moving it into Rescript code and writing unit tests that will run automatically during development and before publishing a new version of the app. This makes our quotes quicker and more reliable.

Get more ideas to improve your self-worth.

I send out a newsletter with simple, practical tips for building web apps with web technologies.

https://twitter.com/GorkaCesium

My 80/20 on HTML:* * *

My most used HTML tag is <div>, which I think stands for the division. I use it because it flows full width, and its block layout is more straightforward for me to think of. So, I end up with a bunch of nested divs that can make it painful to read.

My new approach

I recently started overusing semantic HTML tags that behave precisely like divs on the layout, but for the e-readers they are not the same. Anyways, I find that it increases the readability of my HTML/JSX.

Instead of nesting divs, I try to avoid them. Since I work in components, I use other tags until I really need to use div.

So I will start the component with a <main> and nest <section> tags. Further nesting will follow with <article> tags or any other that make sense. I also use <header>, <footer>, and any other that fits the current component. Anyways, that’s what I’m looking at when I develop components. I don’t look at an HTML document as a whole. I think that semantic HTML tags were initially meant for e-readers and maybe web crawlers, but it is also a great tool to increase developer experience.

I’m not too concerned about the drawbacks. I think that the ease of readability for spotting, which is the closing tag, makes me more efficient than to have a bunch of divs and make mistakes by adding other tags in the wrong place

I hope that helps;

https://twitter.com/GorkaCesium

In the tips and tricks from ReScript Docs, they explain why the following won’t work.

type person = {age: int, name: string}; 

type monster = {age: int, hasTentacles: bool};  

let getAge = (entity) => entity.age;

let kraken = {age: 9999, hasTentacles: true}; 

let me = {age: 5, name: "Baby ReScript"};  

getAge(kraken); 

getAge(me); // type error!

The Problem

🤯
I recently ran to a similar issue, trying to reuse a calculation function with records with some same field names. Taking the same example, let us say I would like to call a function to calculate the age in dog years (1 year for Fido equals 7 years) for person and monster.

let getAgeInDogYears = (entity) => entity.age * 7;

getAgeInDogYears(kraken); 
getAgeInDogYears(me); // type error!

The Trick

💡 The trick to reuse the function is to use accessors.

let getAgeInDogYears = (entity, accessor) => accessor(entity) * 7;

getAgeInDogYears(kraken, entity => entity.age) // works
getAgeInDogYears(me, entity => entity.age) // works!

Trick for Arrays

💻 I write many utility functions that parse or reduce arrays. In this case, the accessor strategy also works.

Array example

Check the following example:

type piggyBank = {
  money: float,
  name: string,
};
type wallet = {
  money: float,
  material: string,
};

let getMoneySum = storages =>
  storages->Belt.Array.reduce(0., (sum, storage) => sum +. storage.money);

let piggyBanks = [|
  {money: 10.20, name: "Johnnys"},
  {money: 120.50, name: "Adrians"},
|];

let wallets = [|
  {money: 100.10, material: "leather"},
  {money: 33.00, material: "plastic"},
|];

getMoneySum(wallets);
getMoneySum(piggyBanks); // type error!

Piggy banks are being rejected by the function even though they have the money field, which is all that matters for calculating the money sum.

Array Trick

Using an accessor, we can make the type checking flexible enough to reuse this utility function.

type piggyBank = {
  money: float,
  name: string,
};
type wallet = {
  money: float,
  material: string,
};

let getMoneySum = (~storages: array('a), ~accessor: 'a => float) => {
  storages->Belt.Array.reduce(0., (sum, storage) =>
    sum +. accessor(storage)
  );
};

let piggyBanks = [|
  {money: 10.20, name: "Johnnys"},
  {money: 120.50, name: "Adrians"},
|];

let wallets = [|
  {money: 100.10, material: "leather"},
  {money: 33.00, material: "plastic"},
|];

getMoneySum(~accessor=store => store.money, ~storages=piggyBanks);
getMoneySum(~accessor=store => store.money, ~storages=wallets);

See the solution in the playground.

I hope that helps!

https://x.com/GorkaCesium

I enrolled in a Bootcamp, which back then was around $500 per month for months of intense learning how to code. I was hungry for knowledge. My participations were a bit too eager. I bet that my eagerness annoyed my classmates. I had a big desire to “conquer the world” of coding. Hung out with the most committed nerds in the classroom and would help each other out.

It was the year when iPhone 4S came out. I had no clue about where to start. Software development was very intimidating to me. The Bootcamp introduced me to C, C++, C#, SQL, and JS. Since it seemed so pricey to go into C#, I ended up going for Javascript, HTML, CSS, which I learned from online guided tutorials like CodeSchool, CodeAcademy, and lynda.com. Now there are many more online learning resources. If I were starting again, I would probably start with Freecodecamp.

I went to meetups, hackathons, talks, and tried to ask people about recommendations. Suddenly, Jorge Zavala offered to pay for the Startup Weekend ticket if I would fly to San Jose, California. That was an eye-opening experience. At the event, I found out about other tech-stacks like ruby on rails, and python, which were much more straightforward than the Microsoft stack. I felt relieved. That made me rethink my strategy for my new career.

The enthusiasm was through the roof. My team was composed of employees from big tech and some super experienced programmers. I witnessed how angel investors approach programmers and offered $20,000 to evolve their MVP.

I came back home with high goals. I wanted to learn. I kept studying online and started building websites and designing web apps as a freelancer. It took me a month to earn my first income, just $100. As I learned more, my output increased. Progressively, I started making more money for the same amount of time. I found out that being a freelancer consisted of part-time hunting for new projects. Getting customers to pay me was also a big-time consumer.

To focus on the technical skills, I got a full-time job where I could code prototypes and websites and use low-code tools to build mobile apps. It was a break to have some steady income. Six months in, a friend invited me to Mountain View to see what it was like to be in 500 Startups. So I quit my job and went there. There I met more programmers, mentors, investors, startups. I heard many success stories. It was incredible. I saw that there was a significant demand for software engineering in the Bay Area. By then, I could build simple web apps client-side.

My job hunt started applying for jobs and learning all that I could about interview questions. People that I met in tech meetups would give me some advice on how to get a job. I also reached out to the network on LinkedIn. Many recruiters started calling me and trying to position me in their client’s companies. Most of it was great advice. After two months and 30+ interviews, I landed a job at a startup in San Jose.

I had a team leader who was very welcoming, patient, and self-thaught computer genius. That is when I started to learn faster than ever before. My learnings were more focused on what mattered, thanks to the mentorship of my team lead and the short feedback loop on code reviews and one-on-one meetings. By summer, he left for a company that was growing exponentially. A few months later, he asked me to join him. That’s how I arrived in Orange County.

There I got hired as a Software Engineer with a 2X pay increase. I could now afford a whole apartment and even save a good chunk of my income. That startup was a lot of fun. I worked intensely, learning from Eric Elliot, Funfunfunctions, the React community, meetups, books, online courses, blog posts, and twitter. Day after day, I voraciously learned and worked. Even a few all-nighters were part of the mix. It was intense. I also had side-projects for learning.

After another year of crazy hard work, I got promoted to Senior Software Engineer. I could not believe it! So soon? I got a raise and more stock options. My recipe was to keep giving value, write blog posts, and run experiments with new tech. All this awarded me credibility and value. My employers compensated for my effort with benefits.

Later I moved on to another company where I kept growing significantly. But that is another story.

You can follow me there as I continue to discover new insights.

How I went from Coding Bootcamp graduate to Senior Software Engineer in 4 years was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

Previous research has suggested that including negative words, such as “not,” in the middle of a sentence can throw off our brains and make it more difficult to understand.

True or False? How Our Brain Processes Negative Statements

As a software programmer, I have noticed that omitting negative operators in the code translates into a more productive code base. In my code reviews, I have encouraged my teams to write in a positive way so it’s easier to understand and work with. This might go against the natural tendency of writing, but it pays off especially as the codebase grows. There are a lot of benefits to writing positive code. In this article, I explain why we should try to avoid negative code as much as possible.

The human mind struggles to understand negative words in statements.

Negative words require more thought process. We can think of thoughts as arrows that have a direction. Negations will flip the logic of the thought.

Do NOT feed the animals

A famous sign in zoos or parks can be “Do not feed the animals.” Many signs have to emphasize the word “not” to help people remember that part of the statement. Have you noticed that they rarely use the compound verb + negation “Don’t” like “Don’t feed the animals”? By separating the negative part it is easier to emphasize. Anyways the mind has to flip the thought.

An easier way to understand could be

Avoid feeding animals

Stop sign is a great example

Stop communicates a simple straightforward idea. Stop. What if this sign would be rewritten to “Do not Go”? It kind of dismisses the negative part.

Good

“Stop”

Bad

“Do not Go”

Positive statements are easier to understand

Straighten out the logic in a statement so it’s easier to read. Avoid the negations as much as possible since that flips the logic. The human mind has to work more to understand a flip in the logic.

A positive thought is:

• easier to read
• easier to peer review
• pushes the writer to improve reader’s experience

For example, compare the following two statements:

Good

“If I get the money I will pay you”. (OK)

Bad

“If I don’t get the money I will not pay you” (so… are you paying me or not??)

The first statement is simpler to grasp. Simplicity consumes less thinking power. The benefit is quicker communication and fewer misunderstandings.

Negative code is tricky to understand

Programming languages have logic operators just like mathematics. Many of the most popular programming languages use == for equality and != for negations. In math would be = and ≠.

In the following code example, we want to write an algorithm. The program will look into a groceries store. The instruction is to buy bananas if they are in stock. Otherwise look in another store.

Good

if (bananasQuantityAvailable == 0) {
  goToAnotherStore()
} else {
  buy(bananas)
}

Bad

if (bananasQuantityAvailable != 0) {
  buy(bananas)
} else {
  goToAnotherStore()
}

An example with ternary expressions

Good

var itemState = itemsCount == 0 ? "Empty" : "Available"

Bad

var itemState = itemsCount != 0 ? "Available" : "Empty"

Easier to mess up when negative code adds up

You might think that it’s quicker to just drop in a negative operator while writing code. That soon becomes a habit and suddenly you start writing negative operators everywhere. That can add up to become a very confusing mess.

Let’s say we want to write a program that will recognize a Tesla car.

For this example, I’ll use the logic operators && for AND and || for OR.

Good

if (isCar && isElectric && isFast && isAwesome) {
  isTesla = true
else {
  isTesla = false
}

Translates to:

It is a Tesla if it is an electric car that is fast and awesome.

Bad

if (!isCar || !isElectric || !isFast || !isAwesome) {
  isTesla = false
else {
  isTesla = true
}

Translates to:

It is not a Tesla if it is not an electric car, and it’s not fast and it’s not awesome.

Our language might be the one to blame

Lera Bododitsky presented in her TedTalk that languages shape the way we think.

One of her examples is about how people will describe bridges. Both Spanish and German relate nouns to genders. In Spanish, a bridge would be masculine “el puente”. The German language also assigns genders to nouns, making “die Brücke” feminine. Hence, Spanish speakers often will refer to bridges with masculine stereotypical adjectives such as “strong” and “long”, while Germans might describe bridges with feminine stereotypes like “beautiful” and “elegant”.

Negative words are part of most languages. The phrases also have them baked in. “If we have them, why not use them?”. We are used to adding negations in our sentences as we are used to including them in our thoughts. Then it seems obvious that we will use negative operators in our code.

When to use negative operators?

There are cases when it makes more sense to use a negative operator. Such a case would be when the negation will still be easy to read, only needs to deal with the negative case, and it will take less code to express.

Closing thoughts

Every time I straighten up a logic statement I witness the power of positive code. Simplifying the codebase is a great dev experience that all the team can benefit from. It’s easier to review and maintain. On the other hand, let’s not take this principle as dogma. Negations are a tool that we can use whenever they make sense.

Thanks for reading and let me know if you have any comments about this principle.

https://x.com/GorkaCesium

Do your job with the highest quality that you can deliver

As you start learning a profession, you might have to accept a lower pay while you gain experience and build your reputation.

Eventually, you will get more demand for your good quality services, which will help you increase your income.

Keep delivering the best quality even if your pay is not that high

If you lower your quality, you risk getting used to deliver sloppy work and you might get stuck in that mindset. Being sloppy will prevent you from earning more.

Adjust your prices with the demand

If your high quality work is in great demand but you undersell yourself, that won’t be sustainable. You would have to work much more than other people in your salary band to earn the same. It will burn you out in the long run.

Conclusion

Strive for excellence and be mindful of how much you are worth.

https://twitter.com/GorkaCesium

Play with the dynamic system

I was frustrated with Excel Spreadsheet’s limitations. I wished I could build unique software apps that could communicate with databases and interact with users. Learning how to write code would free me from depending on someone else to build my ideas.

Changing career seemed risky at that time.

My friends were already established in their jobs or businesses. While I was starting all over again. The only option was to go all in. That’s what many college students lack. That’s how I could achieve so much in a short amount of time. What makes this possible is the person’s grit. Not the bootcamp.

The less you know, the more you think you know.

It’s common that software bootcamp graduates oversell themselves. They claim that after an intensive 4 month training they are mid-level engineers. The reality is that by then they just became “aware” of how software works. Generally they will spread too thin. Studying a broad range of topics from HTML/CSS, web apps, mobile apps, server-side, databases and even Machine Learning.

Software programming seems to be purely logical.

Software programming languages were written by people. A language is built of keywords, commands, interactions and patterns that were all made-up by humans. They are different from the Laws of Nature. Programming languages have human flaws.

As a programmer, it takes time to memorize all those keyword meanings, command functions, and the interactions between each other. Then you have to find out how to work around the flaws that are embedded in the system.

Grab what I just mentioned and multiply it by all the libraries and frameworks that you are adding to your tech stack. It takes time to master all of that.

After you spread too thin, it’s time to dig in.

It’s good to have a bird-eye overview of all the technologies. Now pick your favorite topic and work hard to reach the next level.

Once you level up your HTML and CSS, make sure to bring your JQuery up to par. You feel comfortable with JQuery? Upgrade your vanilla JavaScript. Feel confident? Try ReactJS.

Two steps forward, one step backwards.

Programming technologies are moving fast-forward. It’s hard to keep up with the latest and greatest libraries, frameworks, patterns, tools, and all other sorts of innovations.

Learn a new hyped topic like “async await”. Then go back to the fundamentals by learning how DOM event bubbling works. By balancing trends and fundamentals you will achieve rock solid progress.

If you only focus on the hype topics, your knowledge will be as unstable as a house of cards.

“Skate to where the puck is going, not where it has been.” — Wayne Gretsky

Make an educated guess on what to specialize in. Go to meet-ups. Listen to talks. Follow rockstar developers on Twitter and Medium. Ask senior developers about trending technologies. Ask recruiters about which tech stack are companies hiring for.

Avoid jobs with legacy code bases. You will get stuck in that job since nobody else will be using that tech in a few years. For example, would you take a job that requires you to work on BackboneJS or would you pick the one with ReactJS? The latter is a better option since many companies are adopting it.

Is it a safe bet?

OSS (Open Source Software) projects like languages, tools, libraries and frameworks are more likely to stick in the long run if they are sponsored by a big company like Google and Facebook.

Foundations and crowdfunding are other ways to incentivize OSS.

NodeJS is an example of a project sponsored by the Linux Foundation.

In case of crowdfunding, an important project is webpack, backed up by Open Collective.

Many unsponsored OSS projects become stale because of lack of incentives from the developers.

My bet

• Javascript
• React + Redux
• GraphQL
• App Security
• decentralized apps (blockchain)
• Quality Assurance automation

Get a mentor

Try to get a mentor to help you when you get stuck and to get guidance…

I’ve heard https://www.thinkful.com/ has good mentoring…

and https://freecodecamp.org/ has a big community…

and of course, nodeschool and all the JS meetups.

Get a job as a developer even if you work for peanuts

Whatever you do, only get a job as a developer. In a few years it will pay off. The odds are that you will have a hockey-stick growth in your compensation.

Otherwise you run the risk of getting stuck in another career path.

Mastering code requires full-time dedication.

Junior vs Senior

How do you know someone is of senior-level?

A senior developer is…

Someone who understands the fundamentals of javascript as well as the frameworks and libraries.

Clean Code

In the way of structuring code, senior devs write simpler code, easier to read and maintain.

Juniors try to write too clever code.. and that gets very hard to maintain.

When to optimize

Seniors have the experience to know when it’s worth to optimize some piece of code.. and when to just leave it as it is.

Troubleshooting

As senior would normally get unstuck by himself.

A junior would get stuck for hours or even days in some issue. He will brute force answers from StackOverflow or similar websites to see if they fix his problem.

That is normally due to lack of knowledge on the fundamentals of how software and frameworks work.

Thinking like a machine

A senior dev can write a lot of code before running it because he can mirror in his mind how the code will work.

I hope this was helpful!

Follow me in Twitter https://twitter.com/cuadraman, where I continue to post my learnings and other valuable content.

After using expressJS for a while, I noticed that the HTTP responses from my nodeJS server weren’t compressed. Then I found out about a compressing method called gzip. This method is supported by browsers and speeds up HTTP connections.

To add compression to your node app you can use the npm package compression. This package used to come baked into expressJS. Now you have to installed it separately. Set it up like expressJS middleware. For more details view the docs.

// install it like expressJS middleware
app.use(compression())

Another way is to handle compression on the proxy level. NGINX is an example of web proxies.

Compression can significantly reduce the bytes transfered through the wire. Keep in mind that some clients are limited on the size of applications that they can handle. Maybe you are successful to compress your web app, but when the Android browser decompresses it, it can’t handle the size. Be mindful of the target clients.

https://twitter.com/GorkaCesium

Never forget… to compress on NodeJS was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.