daotoad

Fotos is a spelling error, should be "Photos"

"into an email attachments" doesn't agree on number--it should be "into an email attachment" (singular) or "into email attachments" (plural).

It's not 100% clear that by "shrink" you mean "reduce file size" rather than "visually scale the image".

"Batch image resizer which will make photos smaller enough to fit them all into email attachments. In three easy steps."

Don't use the comparative form of the adjective "small". "Which" is not needed here either.

"Batch Image Shrinker reduces the file size of a group of images in three easy steps:"

That's a start at least. I hope that helps a bit.

The next step is to pay attention and note when you are doing something that seems to take a lot of commands or just generally be inefficient. When you notice this happening, search docs and articles to see if there is a better way to do it.

Over time, you will accrue the things you need to know to use vim effectively.

This is one of the motivating forces behind nvim. While nvim supports vim script, it provides Lua as its preferred language for extension. In addition, the internal APIs are documented and are intended to be accessible from any language via RPC.

https://neovim.io/doc/user/api.html

I was using YCM and ALE to handle completion, but having switched to COC I won't look back. It's just a much better experience.

I got YOU PUT THE SWAYZE IN SWAYZE.

There really needs to be a filter to block these kinds of results.

I wish the word links would let me navigate the set of puns rather than going to google. X links should let me see all the combos that have the same word in the X position. Y links should do the same thing, mutatis mutandis.

I was using ALE for autocompletion and such, but having switched to COC, I find its support for TypeScript to be far superior.

This is relevant because COC is basically a system for talking to language servers.

https://github.com/neoclide/coc.nvim

It's really all about making principled choices when it comes to how much jankiness you can tolerate for a short term velocity boost.

Doing awful things to rapidly try out an idea and see if it warrants further investment is good, as long as you kill the ugly as soon as you understand that your POC is good and you are going to invest further or you know it's not a wise place to invest further.

But there are definitely places where you know you're going to need sanity no matter what. This is anything you know you're going to do a lot, especially under a time crunch. For SaaS work, deployment is one example. In these cases, it's worth investing in building a low friction solution that meets your needs.

This is why I keep coming back to the idea that we need tools that keep their data serialized in the repo itself. I talking about issue tracking, project planning, documentation like github wikis or confluence, all that stuff.

There are quite a few problems to solve to support this that I haven't worked out properly, otherwise I'd be building it.

For example, where do you keep your backlog? How do issues and issue statuses get stored? How do you report on open tickets and progress if the state is scattered across a bunch of different branches?

I personally like being able to establish one identity across multiple services.

This. I've used mine to make:

* an adapter to let me my old vacuum cleaner attachments on my new vacuum

* a number of irreplaceable little plastic gewgaws whose breakage would have destroyed the utility of various products

* custom hooks for use with 3M Command strips

* mounting brackets that let me use some spare casters I had lying around with an Ikea Lack coffee table

So, the thing that google has that I value most is broad single sign-on support.

Is there a service (other than Facebook) that has this capability?

Is there a technology that we should be driving adoption of that would allow me to host my own SSO?

Due diligence like got us the 2007 collapse?

What limited regulation was added after the crisis has been largely undermined.

Because the best way to reduce drunk driving risk is to force everyone out of bars at more or less the same time. Back in my teens and twenties I found myself intervening, with varied levels of success, to prevent drunken trips to the store because "beer-o'clock" was nigh and it was the last chance to obtain more alcohol.

It's always seemed crazy to create a sudden spike in the number of impaired drivers.

What I'd like to see is a comparison of statistics from areas with early last call laws and other jurisdictions with later last call or no restrictions. It would be great to move past what feels good and use some actual data to make a our policies.

Take off every 'ZIG'!! You know what you doing. Move 'ZIG'. For great justice!

In general, diversity makes groups behave better.

Whether by age, gender, race, sexual preference, nationality, or religion, increasing diversity increases the pool of experiences and points of view.

When someone offers up some toxic behavior, it is less likely to be tolerated in a diverse group. We all have in-group attribution bias to some degree, and we find it easier to overlook transgressions in people who we view as like us.

It's also important to be aware of the fact that you don't have to see too many horrible, bigoted comments before a space feels unsafe.

It's not a matter of "not all HN posts", it's a matter of "too many HN posts". And "too many" can be a relatively small number in absolute terms, especially in the context of an industry that has a strong gender imbalance.

The same thing happened with MVC.

MVC was originally used to describe a design using Smalltalk UI widgets as controllers and charts and other similar displays of data as views that worked with business logic stored in the model. State flowed only in one direction, from controller to model to view.

Web MVC completely overthrew that approach and replaced it with something very different with the same name.

All UX was moved to the view, controllers became HTTP endpoints. Communication became bidirectional at both interface layers. View talks to the controller which talks to the model.

When people say they use REST APIs, they aren't.

When people say they are building MVC applications, they aren't.

Except they are. The new meanings that evolved have replaced the original meanings.

Raku's big strengths lie, IMO, in the command line scripting capabilities (the MAIN function), parsing with grammars and powerful new regex syntax, and as a glue language. It's relatively easy to bind to external libraries and work with them.

Look at how easily raku binds to a python charting module in this article: https://www.perl.com/article/plotting-with-perl-6/

I'm in my late 40s and say "Wow, Raku!".

I haven't used it for anything work related yet, but working with it is mind expanding and makes me a better programmer in whatever environment I work in.

The type system, multiple dispatch, literate programming support, and command line scripting features are simply amazing.

> programmers are people too

Are we really?

You might want to look at Carton and cpanfiles as a way of managing dependencies. You can also get really ancient stuff off BackPAN, should your dependencies disappear from CPAN proper.

https://metacpan.org/pod/Carton#Tracking-the-dependencies

http://backpan.perl.org/authors/id/

The reason for the @_ is that it is a simple way to get both pass by value and pass by reference semantics.

The values in @_ are aliased to the values in the subroutine call.

Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.

However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.

Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:

  my %args = @_

Making signatures default will be a big improvement, but the power of the simple abstraction @_ provides should not be underestimated. It's actually an elegant solution to a complex problem.

There is also a concept of "context" in Perl.

An operation may be evaluated in list or scalar context. For example, if you evaluate an array in list context, you get the members of the array, however, in scalar context, you get the number of elements in the array.

This idea is generalized to discuss different evaluation contexts for scalars. You might hear people discussing how a value behaves in boolean or string context. It's also common to talk about casting as "-ification", for example casting something to boolean context is "boolification".

By default, undefined values convert to empty string and 0. However, this can be made to generate a warning or even a fatal exception by setting the appropriate pragmas.

Perl and JavaScript both give you a minimally specified set of tools you can use to build your own more advanced object system.

IMO, that's why both languages have been able to be extended and adapt so much.

If you look at tools like Moo and Moose in Perl and the different coding paradigms that evolved in JS before the "class" keyword was standardized, this is pretty clearly evident.

JS has had the advantage of a standards committee pushing new language features aggressively. Perl has moved more slowly, keeping a majority of functionality in libraries.

My understanding was that Perl's OO system was directly inspired by Python's. I can't find a source on that though.

TIMTOWTDIBSCINABTE (pronounced "tim toady bicarbonate").

"There’s more than one way to do it, but sometimes consistency is not a bad thing either."

Frankly, if you qualify for H1B, you really should qualify for a green card (resident alien status).

Do we really want to bring skilled workers to the US, give them work experience and training that raises their skill level even higher, and then kick them out of the country?

That seems like an unimaginably stupid idea. We should be seeking to retain highly skilled immigrants, not flushing them out of the country.

Microservice architecture is SOA for the 2010s--it's basically agile-ized SOA.

Key features are domain focused services, DevOps friendly deployment via containerization, and continuous integration.

If your teams are defaulting to doing the wrong thing in every case, you are having a crisis of leadership.

The problem might lie in your technical leadership (e.g. making bad design decisions and failing to learn from experience) or from product leadership (e.g. demanding impossibly short turnaround on work, leading to reliance on solutions that are purely short term focused).

You could use MISRA guidelines for C.

https://en.wikipedia.org/wiki/MISRA_C