Postwoman – a free alternative to Postman(github.com)
github.com
Postwoman – a free alternative to Postman
https://github.com/liyasthomas/postwoman
176 comments
Nice timing.
If anyone is interested in how Postwoman was developed and deployed, the author of the project did a huge write up of her tech stack today.
That's at: https://runninginproduction.com/interviews/5-postwoman-is-a-...
If anyone is interested in how Postwoman was developed and deployed, the author of the project did a huge write up of her tech stack today.
That's at: https://runninginproduction.com/interviews/5-postwoman-is-a-...
Yes!! Author here. Please go through this.
I always wonder why some many developers work with Postman (or Postwoman), and so without any automation whatsoever. Example: Requesting some JSON payload and extracting some generated id from it looks like a clumsy point-and-click adventure. With curl, you can use any appropriate program to extract output, say jq:
curl acme.org/my/resource | jq -r '.id'
I guess I don't do enough interesting queries to need a dedicated GUI client. I usually rely on httpie over plain curl or postman. I'd never even heard of insomnia.
For one, the GUI allows you to store your various HTTP actions and replay them, and while you can get that in your shell it takes a bit more work to set it up/present it/reuse it.
I've used it often for ad-hoc requests, where there's authentication/OAuth tokens required, JSON payloads that would be a pain to put into the shell.
Obviously it doesn't negate the need for testing or replace tests, but not every ad-hoc investigation needs to be wrapped in a test.
I've used it often for ad-hoc requests, where there's authentication/OAuth tokens required, JSON payloads that would be a pain to put into the shell.
Obviously it doesn't negate the need for testing or replace tests, but not every ad-hoc investigation needs to be wrapped in a test.
I'm re-writing an API and Insomnia is a required tool because ...
* Non trivial authorisation
* Chained commands
* Templated requests
* Random generation of content
* Non trivial authorisation
* Chained commands
* Templated requests
* Random generation of content
Yea devs that use postman crack me up, in my experience you usually just aren’t writing tests
Exploring an API?
The author is Male. I am not sure just to get attention he brings gender issue in non gender name.
Also it should be good idea to get some other name. The product itself is good.
I am sad to see you get lot of attention because of gender instead of your actual work.
Also it should be good idea to get some other name. The product itself is good.
I am sad to see you get lot of attention because of gender instead of your actual work.
Author here: Ask me anything!
Shoot me any doubts, asks and I'll rectify them.
It should cost 80percent of postman technically.
What should a free version be? PostSlave?
Anyone know how this compares to Insomnia/Postman?
Ever since Postman started getting worse I switched to Insomnia and haven't looked back.
Ever since Postman started getting worse I switched to Insomnia and haven't looked back.
From https://dev.to/liyasthomas/i-created-postwoman-an-online-ope... the author stripped down Chromium for the UI in order to get something much lighter than an Electron app.
> the author stripped down Chromium for the UI in order to get something much lighter than an Electron app.
If an organization did this, I'd be all for it. An individual? I'd bet this is going to slow down updates to Chromium significantly, and eventually lead to either security issues or maintenance fatigue resulting in closure of the project.
I'm not saying it's 100% going to happen like that, but that's on the wrong side of my risk tolerance line for adding a tool to my everyday suite.
If an organization did this, I'd be all for it. An individual? I'd bet this is going to slow down updates to Chromium significantly, and eventually lead to either security issues or maintenance fatigue resulting in closure of the project.
I'm not saying it's 100% going to happen like that, but that's on the wrong side of my risk tolerance line for adding a tool to my everyday suite.
It’s essentially an API testing tool. It is mostly used to poke endpoints on a development server and sometimes to learn the output patterns of a public API, what security concerns are there in stripping the UI?
It's less about the actual changes made and more that one person is maintaining a branch that diverges (significantly?) from upstream, on a project that is fast-paced and constantly under attack. If I'm using this tool to run tests on the network, and I'm several patches of Chromium behind, that makes me vulnerable.
That tradeoff can be worth it, but all I'm getting out of it here is reduced application footprint? I'd rather use the bloated tools or wait for someone with deeper pockets to make a less bloated tool. Or a similarly small project that writes it natively.
That tradeoff can be worth it, but all I'm getting out of it here is reduced application footprint? I'd rather use the bloated tools or wait for someone with deeper pockets to make a less bloated tool. Or a similarly small project that writes it natively.
I haven't exactly dug into the codebase, but "stripped down Chromium for the UI" could very well mean CEF, which is widely-used by a lot of things (commercial and otherwise) and directly supported by Google. However, whether that's more lightweight than Electron is debatable.
If that concerns you, though (or if the author really did outright fork Chromium), it looks like it runs in an ordinary browser, too (e.g. via postwoman.io or localhost:3000).
If that concerns you, though (or if the author really did outright fork Chromium), it looks like it runs in an ordinary browser, too (e.g. via postwoman.io or localhost:3000).
I'm just going off the following quote:
> the author stripped down Chromium for the UI
If it's just CEF then I feel like that wording is misleading.
> the author stripped down Chromium for the UI
If it's just CEF then I feel like that wording is misleading.
>Ever since Postman started getting worse I switched to Insomnia and haven't looked back.
Curious to know what you feel as been getting worse with Postman?
I'm a long time user of it myself and feel it has consistently done what it says it will do without much cruft.
Curious to know what you feel as been getting worse with Postman?
I'm a long time user of it myself and feel it has consistently done what it says it will do without much cruft.
Really like the simplicity of the testing integrated with it
How does Insomnia compare to Paw [1]?
[1] https://paw.cloud/
[1] https://paw.cloud/
Hi! Creator of Insomnia here :)
The main differences are that Paw is a native Mac app, paid, and closed source.
Insomnia is open source, cross-platform, and free to use (although there is a paid plan).
Some of Insomnia's biggest differentiators are it's GraphQL query editor (autocomplete, linting, etc) and it's ability to be customized via plugins and themes.
The main differences are that Paw is a native Mac app, paid, and closed source.
Insomnia is open source, cross-platform, and free to use (although there is a paid plan).
Some of Insomnia's biggest differentiators are it's GraphQL query editor (autocomplete, linting, etc) and it's ability to be customized via plugins and themes.
GraphQL is the reason I just switched from a paid Paw license to insomnia!
Thank you for the reply!
Insomnia is fantastic. Never looked back to postman.
Insomnia is great!
It's GraphQL support is lovely.
I'm curious about whether the product name "Postwoman" violates Postman's trademark and whether Postwoman will be getting a C&D letter soon, demanding that the name be changed.
Normally companies don't get to claim broad trademark protection for prefixes -- Facebook has been shut down when trying to broadly enforce its trademark against anything prefixed with "Face" -- but "Postwoman" is close enough and is marketed as a competing product in the same place.
Update: It seems the author is also worried about this. On her blog post announcing the service, someone raised the concern, and she acknowledged that it's a problem: https://dev.to/liyasthomas/comment/ee8m
Normally companies don't get to claim broad trademark protection for prefixes -- Facebook has been shut down when trying to broadly enforce its trademark against anything prefixed with "Face" -- but "Postwoman" is close enough and is marketed as a competing product in the same place.
Update: It seems the author is also worried about this. On her blog post announcing the service, someone raised the concern, and she acknowledged that it's a problem: https://dev.to/liyasthomas/comment/ee8m
It's like one of those marketing things - at some point or another Postman will need to decide what to do here. If they go after them, postwoman will get tons of "free" publicity and probably get the PR win, even if it means renaming to "Post Woman" (with a space) or declaring they will fight it in court.
If Postman decides NOT to pursue it, some users may simply be turned off to the fact that they decided to invade the space of Postman with a similar name. I and probably others would probably have respected a different name altogether.
If Uber got a competitor called Ubor people would probably also be annoyed.
If Postman decides NOT to pursue it, some users may simply be turned off to the fact that they decided to invade the space of Postman with a similar name. I and probably others would probably have respected a different name altogether.
If Uber got a competitor called Ubor people would probably also be annoyed.
> If Postman decides NOT to pursue it
Choosing not to pursue it can put the trademark at risk.
So even if Postman would otherwise shrug, it may need to pursue it to protect its right to the mark.
Choosing not to pursue it can put the trademark at risk.
So even if Postman would otherwise shrug, it may need to pursue it to protect its right to the mark.
No, They really do not
EFF is debunked this myth many many many times I wish people would stop spreading it, as it just an excuse for Over Aggressive enforcement that companies that DESIRE to do it use to divert the bad PR, "We had no choice" sounds alot better than "We want to crush any competition"
EFF is debunked this myth many many many times I wish people would stop spreading it, as it just an excuse for Over Aggressive enforcement that companies that DESIRE to do it use to divert the bad PR, "We had no choice" sounds alot better than "We want to crush any competition"
Do you have a link to one of those debunkings? I'd like to read it, thanks in advance.
Searching the EFF site found me “Trademark Law Does Not Require Companies To Tirelessly Censor the Internet”: https://www.eff.org/deeplinks/2013/11/trademark-law-does-not...
> Second, Canonical is not “required” to enforce its mark in every instance or risk losing it. The circumstances under which a company could actually lose a trademark—such as abandonment and genericide—are quite limited. […] Courts also set a very high bar to show abandonment (usually years of total non-use). Importantly, failure to enforce a mark against every potential infringer does not show abandonment.
That paragraph cites the court decision https://scholar.google.com/scholar_case?case=950778076210138...:
> The evidence in this case shows that Metalock Corp. has and is continuing to take reasonable steps to maintain its rights in the mark, to use that mark, to license its use, to advertise it and to prosecute infringers. The owner of a mark is not required to constantly monitor every nook and cranny of the entire nation and to fire both barrels of his shotgun instantly upon spotting a possible infringer. Lawyers and lawsuits come high and a financial decision must be made in every case as to whether the gain of prosecution is worth the candle. These defendants have not proved that because of the lack of efforts by plaintiffs in "policing" use of the mark, that METALOCK has become so diluted by widespread use by others that it has lost its distinctiveness.
My interpretation is that companies do indeed have to prosecute a high enough fraction of infringements to protect their trademark, but they don’t necessarily have to prosecute a given infringement. So, for example, Postman could keep their trademark if they left “Postwoman” alone, as long as they later sued “Post Man” for infringement.
> Second, Canonical is not “required” to enforce its mark in every instance or risk losing it. The circumstances under which a company could actually lose a trademark—such as abandonment and genericide—are quite limited. […] Courts also set a very high bar to show abandonment (usually years of total non-use). Importantly, failure to enforce a mark against every potential infringer does not show abandonment.
That paragraph cites the court decision https://scholar.google.com/scholar_case?case=950778076210138...:
> The evidence in this case shows that Metalock Corp. has and is continuing to take reasonable steps to maintain its rights in the mark, to use that mark, to license its use, to advertise it and to prosecute infringers. The owner of a mark is not required to constantly monitor every nook and cranny of the entire nation and to fire both barrels of his shotgun instantly upon spotting a possible infringer. Lawyers and lawsuits come high and a financial decision must be made in every case as to whether the gain of prosecution is worth the candle. These defendants have not proved that because of the lack of efforts by plaintiffs in "policing" use of the mark, that METALOCK has become so diluted by widespread use by others that it has lost its distinctiveness.
My interpretation is that companies do indeed have to prosecute a high enough fraction of infringements to protect their trademark, but they don’t necessarily have to prosecute a given infringement. So, for example, Postman could keep their trademark if they left “Postwoman” alone, as long as they later sued “Post Man” for infringement.
Are you serious? Or are you satirizing the "need to defend IP or lose it" meme?
I seriously cannot imagine the word "postman" falling into genericide on this basis.
I seriously cannot imagine the word "postman" falling into genericide on this basis.
Refusing or failing to pursue action against a violation of a trademark can cause a trademark to be considered abandoned and therefore invalid. It is a genuine legal concern. This is supposed to prevent individuals and companies from “sitting” on a trademark without the intention of using it.
So you are saying that you think that "Postman" declining to pursue legal action against "Postwoman" might lead to a court deciding that "Postman" is a generic mark - do I have that correct?
Can you point to a case even vaguely close to this fact pattern?
Can you point to a case even vaguely close to this fact pattern?
>So you are saying that you think that "Postman" declining to pursue legal action against "Postwoman" might lead to a court deciding that "Postman" is a generic mark
Per this posting from a law firm [1], as your question is stated with the inclusion of "might" the answer is yes. Apparently it can go one of three ways: abandoning, not impacting/abandoning, or diminishing. Two of these results are bad for the trademark holder.
I'd assume a C&D letter would be sufficient to get a proper result or at least should be the first move in these matters, but I'm not a lawyer nor play one on TV or online.
[1] https://www.dbllawyers.com/can-lose-trademark-rights-dont-su...
Per this posting from a law firm [1], as your question is stated with the inclusion of "might" the answer is yes. Apparently it can go one of three ways: abandoning, not impacting/abandoning, or diminishing. Two of these results are bad for the trademark holder.
I'd assume a C&D letter would be sufficient to get a proper result or at least should be the first move in these matters, but I'm not a lawyer nor play one on TV or online.
[1] https://www.dbllawyers.com/can-lose-trademark-rights-dont-su...
There are tons:
https://en.wikipedia.org/wiki/List_of_generic_and_genericize...
You don't necessarily need to sue competitors for being misleading, but you do generally have to show you are trying to defend your trademarks and a lawsuit is a nice expensive papertrail.
https://en.wikipedia.org/wiki/List_of_generic_and_genericize...
You don't necessarily need to sue competitors for being misleading, but you do generally have to show you are trying to defend your trademarks and a lawsuit is a nice expensive papertrail.
I assert that literally zero of these cases are even close to this one in terms of the degree of abandonment represented by failure to take action against Postwoman.
Can you specify a single one that you think is similar?
Can you specify a single one that you think is similar?
You could have made a simple search and found more confirmation than I could possibly provide. Even the USPTO has top-level search results to that effect.
https://www.google.com/search?q=failure%20to%20protect%20tra...
https://www.google.com/search?q=failure%20to%20protect%20tra...
Which of these cases specifically do you assert is similar to this one?
Trademarks have to be defended or else you can indeed lose it. That's a fact. Copyrights on the other hand are not the same. You may be confusing the two and lumping them all together under "IP" but there are many legal differences between different types of IP.
I am very familiar, and have formally studied, trademark genericization. Your patronizing comment is not helpful.
Can you point to a mark that you think was genercized in a similar fashion to what you project happening if Postman does not pursue legal action against Postwoman?
Can you point to a mark that you think was genercized in a similar fashion to what you project happening if Postman does not pursue legal action against Postwoman?
Not a lawyer, but in this particular case it appears they reaffirmed the lower court stating the vendor couldn't sell products with trademarked Greek organization lettering (though he could make up ones using the Greek alphabet as demonstrations) and that they could continue to sell their "double raised crest backing" paddle which the group was requesting they be banned from doing.
So the trademark was protected it would appear. Even though the infringing company makes a good case (laches) for selling said products without regard from the fraternities/sororities for decades (in fact, they were selling to these organizations, so they were generally aware of the company's existence and practices).
So the trademark was protected it would appear. Even though the infringing company makes a good case (laches) for selling said products without regard from the fraternities/sororities for decades (in fact, they were selling to these organizations, so they were generally aware of the company's existence and practices).
...that case supports my argument, not yours. Not sure why you are linking it.
[deleted]
Sorry but I trust the EFF more than I trust you
https://www.eff.org/deeplinks/2013/11/trademark-law-does-not...
>>>Quite simply, the view that a trademark holder must trawl the internet and respond to every unauthorized use (or even every infringing use) is a myth. It’s great for lawyers, but irritating and expensive for everyone else. And when done clumsily or maliciously, it chills free expression.
https://www.eff.org/deeplinks/2013/11/trademark-law-does-not...
>>>Quite simply, the view that a trademark holder must trawl the internet and respond to every unauthorized use (or even every infringing use) is a myth. It’s great for lawyers, but irritating and expensive for everyone else. And when done clumsily or maliciously, it chills free expression.
Trademarks are protected to prevent fraud and impersonation of other companies. So we don't want to accidentally mistake a e.g. gougle product as a google one. That was the very legal intention of trademark laws.
In the case of postwoman, it's kind of hard to imagine anyone would mistake it for postman. So it's unlikely postman would win a lawsuit against it.
In the case of postwoman, it's kind of hard to imagine anyone would mistake it for postman. So it's unlikely postman would win a lawsuit against it.
https://www.openbook.social got into trouble for this exactly.
IANAL but the basic sniff test is could "Postwoman" be confused with "Postman?" I think the answer is yes. With the author calling it an alternative to "Postman," you have the author acknowledging Postman is a strong trademark. And it's not like it's the only one available fitting the "{HTTP-METHOD}{MAN|WOMAN}" construct-- you could rename it "HeadWoman" and probably be okay.
And I don’t think GETwoman or PUTWoman would be good either, as there’s other apps for that.
If she named it Going Postal, how old would one need to be to get the reference?
What if the name were changed to Pos2man? ^_^
Author here: I think this is funny because few reads it: posTWOman :/
I wouldn't have either except that your flying saucer logo (https://raw.githubusercontent.com/liyasthomas/postwoman/mast...) really emphasizes the TWO. :D
I could imagine the optics of going after a project named "Postwoman" would lead Postman to not pursue this.
Zero chance of that being a primary issue when you're dealing with a directly competing product.
If they allow their trademark to go unprotected from an extremely blatant hit like this, their trademark might as well be worthless. Having a competing product in the market using an intentionally similar name, is a large value debasement for the Postman brand & offering (not to mention the $58m in venture capital that is betting on the value of those things).
Is Postwoman from the Postman company? They're similar products? Are they competing products from the same company? The sound you hear is millions of dollars in venture capital being flushed down the toilet.
No serious company is going to hold back on a legal response just because you staple woman/women/her/she to their existing trademarks and seek to compete head-on with their products or services.
If they allow their trademark to go unprotected from an extremely blatant hit like this, their trademark might as well be worthless. Having a competing product in the market using an intentionally similar name, is a large value debasement for the Postman brand & offering (not to mention the $58m in venture capital that is betting on the value of those things).
Is Postwoman from the Postman company? They're similar products? Are they competing products from the same company? The sound you hear is millions of dollars in venture capital being flushed down the toilet.
No serious company is going to hold back on a legal response just because you staple woman/women/her/she to their existing trademarks and seek to compete head-on with their products or services.
Trademark laws are about consumer protection which is why companies must enforce their trademark or they risk losing it. In this case, I initially thought Postwoman was a spinoff of Postman built by the same team (not sure why they would do this but I guess representation is all the rage nowadays). If a consumer could mistake the product as a different one then it's grounds for trademark violation.
Disclamer: I am not a lawyer but I have at least a high level understanding of trademark law.
Disclamer: I am not a lawyer but I have at least a high level understanding of trademark law.
Not well educated in trademark law, but given how The South Butt, LLC fared, I'd guess Postman could win if they decided to sue. https://en.wikipedia.org/wiki/The_South_Butt
There's lot of projects like: Next, Nest, Nuxt.. I wonder how this would apply to them.
Huh .. Postman is MPL-2.0 is seems, but it is also a commercial operation (and even non-commercial organizations often hold and protect trademarks like Mozilla). It's not a joke or broken project, so it wouldn't be protected under parody. I too am curious if Postman will go after this project to defend their trademark.
Postman is so horrendously slow when using a quite large "team space". I should really explore the alternatives
How does this compare to insomnia.
https://github.com/getinsomnia/insomnia
https://github.com/getinsomnia/insomnia
It looks like Postwoman is is more of a simple utility right now. Perhaps it will grow to something more full-featured in the future but that seems to be the main differentiator right now. Insomnia, for example, supports environment variables, a GraphQL IDE, plugins, and many different authentication formats.
As the creator of Insomnia, I love seeing new projects like this and am really excited to see what Postwoman grows into. It looks awesome, is open source, and there's always room for more developer tools! :)
As the creator of Insomnia, I love seeing new projects like this and am really excited to see what Postwoman grows into. It looks awesome, is open source, and there's always room for more developer tools! :)
Just a side note: Insomnia was recently acquired by Kong (the API gateway): https://konghq.com/blog/kong-acquires-insomnia/
so happy that you mentioned this, my first time hearing of this. this is why I love HN, someone always has a suggestion/alternative!
Going to use this instead of Postman now!
Going to use this instead of Postman now!
I'm all for anything killing Electron
Does anybody else take a project a _lot_ less seriously when all of their documentation and commit messages are plastered with emojis? I feel like I can't create a cohesive narrative in my mind when every sentence ends with a unicorn or a rainbow or a volcano.
When emoji use follows a strict convention (something like https://gitmoji.carloscuesta.me/), it can make it easier to scan a list of commits and get a rough idea of where the development focus is (i.e., hardening vs. feature development).
I've seen this convention before. I personally find it more useful to tag commit messages with [fix], [docs], etc. It makes it more easily searchable, which is IMO what you really want. You can:
Emojis feel... complicated. What do they mean? Here you're just typing the literal word so not much to remember or search.
git log --pretty=oneline --abbrev-commit | grep "\[doc"
Emojis feel... complicated. What do they mean? Here you're just typing the literal word so not much to remember or search.
Using emojis feels a bit cliquey, in-groupy. It's an extra barrier to a new developer wanting to get familiar with the project or contribute a quick fix. And you know people are going to get emojis mixed up because different associatons come to mind for different people, so project committers are going to have to be diligent about noticing and correcting mistakes. For me, the effect is the opposite of the casual and inviting atmosphere I think they're intended to create.
>Emojis feel... complicated. What do they mean?
My first smartphone was a Galaxy S2, and I frequently used an emoji that looked like a character giving a sly winking-type gesture.
It took me several years to realize that this was actually the eye-rolling emoji, and every other system's implantation clearly showed this. Some of the more strange responses I received started to make sense.
My first smartphone was a Galaxy S2, and I frequently used an emoji that looked like a character giving a sly winking-type gesture.
It took me several years to realize that this was actually the eye-rolling emoji, and every other system's implantation clearly showed this. Some of the more strange responses I received started to make sense.
You can't search by arbitrary Unicode characters?
It isn't unicode. I cloned the repo, this is the commit message in the command line:
Why not just use "[rotating_light] Lint" as the commit message? Or even better: "[lint] Make changes recommended by foo lint\n\nThis is the foo command used: ..."
:rotating_light: Lint
Why not just use "[rotating_light] Lint" as the commit message? Or even better: "[lint] Make changes recommended by foo lint\n\nThis is the foo command used: ..."
That is far too much vocabulary to use effectively. A single-word designation would be much easier to discern and easier to translate. A word can be translated in a way that is meaningful but the “obvious” associations of the emojis may not make any sense in the context of a different language. Replacing language with inscrutable symbolism is bad design.
I really would like to see how Linus would react to a PR with commit messages like this.
I've been using the same branching strategy for about 5 years, and it has worked really well. I suspect it's fairly common, although everywhere I've worked we've switched to this from something with less structure. Essentially the branch naming pattern looks like:
The emoji thing is fine if it's for fun - we should all enjoy ourselves and our work a little more - but I'm hard pressed to see the practicality of it.
[ticket-type]/#TICKET-[ticket-description]
bug/APP-123-prevent-auth-redirect-loop
The emoji thing is fine if it's for fun - we should all enjoy ourselves and our work a little more - but I'm hard pressed to see the practicality of it.
> I'm hard pressed to see the practicality of it.
The first thing that comes to mind is that it takes up less space and is thus easier to scan. Also, people with visual impairments may have an easier time scanning based on color/shape rather than reading each individual line.
Also, it's just as easy to grep for ':bug:' than 'bug', or rather, it's more specific to do so. Likewise, people suggesting [bug] have to worry about whether their shell or grep is going to interpret the square brackets (they will).
git log | grep '[bug]' - does not do what you want
git log | grep [bug] - fails in ZSH; works as above in bash
git log | grep bug - matches lots of things, not just the tag
git log | grep ^bug - Doesn't work because 'git log' puts spaces in front of commit lines
git log | grep :bug: - Does exactly what you expect it to and nothing else.
That's the practicality that I see, personally.
> you don't need to worry about emojis rendering differently on different platforms
You don't really need to worry about that anyway, as long as you're generally on the same one or two platforms. A user on Ubuntu will always see the same bug, even if :bug: gives them a different bug illustration than an iOS user sees. In the git commits, it's represented as the tag (:bug:) and not the literal emoji.
Lastly, I fail to see anything that has to do with branching strategy with regards to emoji. This is purely commit messages and (in this case) the readme. Your branching strategy doesn't tell us anything about individual commits.
The first thing that comes to mind is that it takes up less space and is thus easier to scan. Also, people with visual impairments may have an easier time scanning based on color/shape rather than reading each individual line.
Also, it's just as easy to grep for ':bug:' than 'bug', or rather, it's more specific to do so. Likewise, people suggesting [bug] have to worry about whether their shell or grep is going to interpret the square brackets (they will).
git log | grep '[bug]' - does not do what you want
git log | grep [bug] - fails in ZSH; works as above in bash
git log | grep bug - matches lots of things, not just the tag
git log | grep ^bug - Doesn't work because 'git log' puts spaces in front of commit lines
git log | grep :bug: - Does exactly what you expect it to and nothing else.
That's the practicality that I see, personally.
> you don't need to worry about emojis rendering differently on different platforms
You don't really need to worry about that anyway, as long as you're generally on the same one or two platforms. A user on Ubuntu will always see the same bug, even if :bug: gives them a different bug illustration than an iOS user sees. In the git commits, it's represented as the tag (:bug:) and not the literal emoji.
Lastly, I fail to see anything that has to do with branching strategy with regards to emoji. This is purely commit messages and (in this case) the readme. Your branching strategy doesn't tell us anything about individual commits.
> git log | grep ^bug - Doesn't work because 'git log' puts spaces in front of commit lines
No, but this does work:
No, but this does work:
git log --grep ^bugA simple text string would be much faster to search in a browser or command line.
Most browsers would highlight all the matches.
On top of that, emojis are much less friendly to visually impaired people.
Most browsers would highlight all the matches.
On top of that, emojis are much less friendly to visually impaired people.
[deleted]
Easier to glance at an emoji than a commit message. Thanks for this guide.
Emojis look different on different operating systems (and sometimes don't even render)...
I'd argue that the tone is what matters most and not the presence of emojis. For example, this is an example of a particularly bad changelog which isn't sprinkled with emojis.
https://github.com/nodejs/node/blob/v2.5.0/deps/npm/CHANGELO...
Imagine trying to handle a production incident, going through such a changelog, reading "HAHA WHOOPS LIL SHINKWRAP ISSUE THERE LOL".
>
Imagine trying to handle a production incident, going through such a changelog, reading "HAHA WHOOPS LIL SHINKWRAP ISSUE THERE LOL".
>
Though not a library, Discord also seems to love using this style for their changelogs.
I'm not a fan.
I'm not a fan.
No, emojis are incredibly expressive and enrich all forms of writing. I'm excited to see this style of communication penetrate more spaces :slightly-smiling-face:.
Edit: The emoji I added to the above message was stripped by HN's submission system.
Edit: The emoji I added to the above message was stripped by HN's submission system.
>Edit: The emoji I added to the above message was stripped by HN's submission system.
One more reason to love HN
One more reason to love HN
⭐ I hope 🇺🇸my comment doesn't revert ↩️ your opinion. ⭐
"We can't be bothered to properly handle Unicode" is not a great look for technologists.
It's an intentional design decision as far as I know (there was a phase where it did support them, and people didn't like it, and I think the block isn't perfect, so some emoji are still possible)
[deleted]
Has the advantage of not allowing emojis, and I can still post this
| ٧ | ٦ | ٥ | ٤ | ٣ | ٢ | ١ |
Win-win
| ٧ | ٦ | ٥ | ٤ | ٣ | ٢ | ١ |
Win-win
జ్ఞ ా
何言ってんの？ この掲示板には、バカな文字だけが禁止。
wehrkeoruw(2)
> No, emojis are incredibly expressive and enrich all forms of writing.
I certainly find many (almost all?) highly ambiguous, which is the total opposite of expressive in my opinion.
I'm aware I will sound "old man shouts at cloud" to some, but if you need emojis to express yourself, you are lacking language skills.
I certainly find many (almost all?) highly ambiguous, which is the total opposite of expressive in my opinion.
I'm aware I will sound "old man shouts at cloud" to some, but if you need emojis to express yourself, you are lacking language skills.
[deleted]
[deleted]
+1.
I personally think that first part of the readme made good use of them and kinda helped me navigate the different sections, but they're very distracting in the commit messages, H1s and the description.
Not every line needs an emoji at the beginning or end, and IMO rarely does it need both.
Emojis in text IMO are like jokes in movies. The funnest movies have them, they're placed well and they're effective. Other movies have so many of them they just pull you from the story and then you just can't relate.
I personally think that first part of the readme made good use of them and kinda helped me navigate the different sections, but they're very distracting in the commit messages, H1s and the description.
Not every line needs an emoji at the beginning or end, and IMO rarely does it need both.
Emojis in text IMO are like jokes in movies. The funnest movies have them, they're placed well and they're effective. Other movies have so many of them they just pull you from the story and then you just can't relate.
Absolutely, maybe I'm not with the trends but it seems unprofessional and doesn't add much value (for myself)
I see it a lot on here as well, even in very source heavy or scientific posts. It rubs me the wrong way when a post ends with ;)
I personally dislike prettifying of text interfaces with forced conventions/icons/*mojis. Text interface is well, should be text. There are well defined conventions and tools built around these conventions.
Tag with [tag], use consistent spacing etc. and, make it easy on the eyes.
Same with glorified .bashrc files used to create graphic-git command prompts.
Tag with [tag], use consistent spacing etc. and, make it easy on the eyes.
Same with glorified .bashrc files used to create graphic-git command prompts.
There is no difference between a glyph that displays a letter and a glyph that displays an image, it's an arbitrary matter of the encoding between code points and a font. And as emoji are already part of Unicode, they're just as much "text" as ASCII.
That's technically correct but, when working with console and text processing stuff emojis and other multi-byte characters complicate the things sometimes.
My native language also requires unicode characters to type correctly, and they create the same problems hence, I also prefer avoiding these characters.
These are my preferences, I cannot (and should not) stop the progress. However for me, simplicity and practicality is much better than fanciness.
I'd not fight over this stuff if I was contributing to a project which embraces these concepts and play along without any fuss or objection but, I won't use these in my own projects.
My native language also requires unicode characters to type correctly, and they create the same problems hence, I also prefer avoiding these characters.
These are my preferences, I cannot (and should not) stop the progress. However for me, simplicity and practicality is much better than fanciness.
I'd not fight over this stuff if I was contributing to a project which embraces these concepts and play along without any fuss or objection but, I won't use these in my own projects.
I know I don't. It's one thing to sprinkle some fun here and there, but I have seen many projects (JS mostly) with so many unicorn emojis everywhere, and a huge logo in it's GitHub readme. It's not that the library name is self explanatory either.Mocha, Jasmine, Karma.. do they _really_ sound like testing frameworks?
The whole issue is further amplified by the fact that the imagery isn't even remotely related to the actual content. Even the current latest commits list on the repo homepage has commits ":rotating_light: Lint" and ":zap: Lint".
Does changing : rotating_light: to :rotating_light: (removing a space) require rewriting history in git? does it mean people who have cloned the repo will need to (yuck) force pull?
Author here: That was prolly a mistake made by me. Sorry.
Perhaps it makes initially using the project seem more fun and approachable from a first glance? I am a hardened bitter old fart, but I like them. :)
Author here: I love emojis because they are fun and makes it enjoyable. I don't look for the technicality behind it.
Author here: Sorry if my usage of emojis made you uncomfortable. I don't think using emojis would soften the seriousness of a project There's lot of projects that uses Gitmoji and it's all v.appreciated too. Don't make someone feel lesser when you don't like it. I like to keep a signature on everything I do, whether its commit messages or anything else.
Don’t mind the fun police. Everything does not have to be grayscale only, especially not a volunteer project.
Yeah, it’s juvenile and cheeky. Not what I’m looking for when I just want to find what I need efficiently when I look through docs...
Can you define "Plastered"? From what I can see, of the most recent 35 commits, there exist seven emoji, plus one that would have been but was a typo. Also, none of them are unicorns or rainbows or volcanoes.
I'm wondering if you're referring to a different project that you've seen and were just reminded of it, or if you're exaggerating because you saw something you didn't like.
Also, using visual indicators is nothing new; Jenkins uses thunderstorms and suns to denote build status, and marketing pages are often full of images, icons, and iconography.
The reality is, the younger generation communicates differently than the older generation, and different subcultures communicate differently from each other. Maybe you take someone less seriously because of the way they communicate, but that's on you, not on them.
I'm wondering if you're referring to a different project that you've seen and were just reminded of it, or if you're exaggerating because you saw something you didn't like.
Also, using visual indicators is nothing new; Jenkins uses thunderstorms and suns to denote build status, and marketing pages are often full of images, icons, and iconography.
The reality is, the younger generation communicates differently than the older generation, and different subcultures communicate differently from each other. Maybe you take someone less seriously because of the way they communicate, but that's on you, not on them.
The problem with emojis is that they render inconsistently in different mediums and there are better ways to communicate the same intent, especially to users less familiar with emoji usage. For a project like this I think its alright, it adds spunk to a already spunky project (I define spunky as gung-ho competing with a funded and mature project because you think you can do a better job - which I support). I disagree with their usage in the h1 tags and a few other places because I think it looks bad, but its not my project and not a massive deal regardless.
All said I don't like the name because it puts Postman in a tough situation, keep the gender pronoun if you want just don't make it near identical to them.
All said I don't like the name because it puts Postman in a tough situation, keep the gender pronoun if you want just don't make it near identical to them.
Personally they've has helped with the automated messages my team's software pushes into project management system because they visually represent what type of message was pushed.
Seems like it's doing the same thing here, I kind of hope to see more of it!
Seems like it's doing the same thing here, I kind of hope to see more of it!
[deleted]
I don't like having a lot of emoji in it either, but if the words are still readable then it can still be readable and seriously enough.
Personally doesn't bother me. It definitely gives a more playful theme which I think is a good thing instead of trying to read a wall of just text documentation.
postwoman(2)
So I guess commit messages support emojis now.
I've seen this before, but not quite so consistently.
I've seen this before, but not quite so consistently.
Why does the word ‘woman’ look like a derivative of the word ‘man’? I think it’s unfair! (The term ‘female’ is no big help, either.)
Because it isn't a derivative of it.
Have a listen to this podcast by a linguist: https://news.ycombinator.com/item?id=21607712
The short answer is the modern word woman has a separate etymological root than the word man. And the word man has had linguistic changes recently that mask those origins. Woman as well actually.
Man originally meant human really, and woman used to be Wifman (somewhat literally female human). Wife is a holdover from this prior to Middle english usage of the term.
Old english used wer and wif as man/woman respectively, and as you can guess Werewolf derives from the old ussage of man.
In short, its complicated and woman isn't a derivative of man. Its much more interesting than that. You can't look at the modern spelling of words to derive much on how we got to this point. You'll make a ton of categorical errors that way, especially in English given man used to just be the human race. Our modern take of man anywhere as needing to be replaced with woman depending on gender is slightly amusing once you know the etymology of the term in that regard.
Have a listen to this podcast by a linguist: https://news.ycombinator.com/item?id=21607712
The short answer is the modern word woman has a separate etymological root than the word man. And the word man has had linguistic changes recently that mask those origins. Woman as well actually.
Man originally meant human really, and woman used to be Wifman (somewhat literally female human). Wife is a holdover from this prior to Middle english usage of the term.
Old english used wer and wif as man/woman respectively, and as you can guess Werewolf derives from the old ussage of man.
In short, its complicated and woman isn't a derivative of man. Its much more interesting than that. You can't look at the modern spelling of words to derive much on how we got to this point. You'll make a ton of categorical errors that way, especially in English given man used to just be the human race. Our modern take of man anywhere as needing to be replaced with woman depending on gender is slightly amusing once you know the etymology of the term in that regard.
The big rant I keep seeing around the internet is https://i.imgur.com/6g45AxX.png
Unfortunately your link doesn't seem to be correct.
Incidentally, the "-man" in "postman is pronounced like the -"man" in "woman", not like "man".
Author here: Wow i never knew this. Thanks for sharing this.
One can also see a male as 2/3 of a female or as a Fe-male with an iron deficit.
Or you could see it as man + (something) -- i.e. better than man. It really depends on how you take a normal word and assign an agenda to it.
Ditto "man" and "he" being used when the sex of the person in question isn't known, or as a poetic stand-in for "human"—the usual complaint about that is that it implies maleness is "normal" at the expense of women but it could just as easily be seen as erasing what's distinctive about maleness, at its expense and in favor of women, who get their own dedicated words that aren't multi-purposed and also used to refer to men in some cases. Just a matter of perspective who's harmed by it (if you take anyone as being harmed).
What’s the difference between this name and postman2?
Original Show HN by the creator 3 months ago: https://news.ycombinator.com/item?id=20817627
Author here: yep, that was me.
I don't see a feature where you can create tests for responses which is a very important feature for me that exists in Postman
Maybe I'm missing it, but I'm not seeing the full response headers, just "cache-control" and "content-type". Being able to see the full response headers would make this a much more useful tool for debugging APIs.
Would you like to report the issue faced on GitHub so that we could track and rectify them really quick.
I'm encouraged by the GraphQL support with docs, except there appears to be no way to provide headers (such as Authorization), which means I can't even fetch my schema.
Author here: GraphQL support is just landed on PW. Expect all functionalities in a month. Follow the project on GitHub.
If Postwoman doesn't tickle your fancy, I'd take a look at https://github.com/pashky/restclient.el. (I believe there's a vim equivalent, too.) You can save requests in a simple .http file, and check them into your codebase. Makes collaboration very simple.