Showing posts with label workaround. Show all posts
Showing posts with label workaround. Show all posts

Wednesday, April 13, 2022

Read Medium Articles For Free

 There is nothing more annoying to someone who is just trying to read about something they are trying to learn about, than to have a site say, "Hey, you've reached your 'free' limit!".  That is exactly what medium.com does with its articles.  You need to log in to read further (so it says), and then, when you do, they STILL won't let you go any further until you pay for the right to read their articles.  Call me cheap, but I believe in the freedom of information.  

So, a little Google-foo and I discovered that there is a workaround for this that works in Chrome/Brave:

- Load up the article you want to read

- In the URL bar at the top, click the little padlock (the one that indicates that the site is secured)

- In there, it will tell you how many cookies there are.  Click on "Cookies".  It will bring up a window similar to this:


- Click on 'medium.com' and click 'Block' down below, and then Done.


Chrome/Brave will then ask you to reload the page.  Once you do, you should be able to read the article without the annoying message telling you that you haven't paid them for the privilege yet.  

Enjoy! 


**UPDATE:  I know its been quite a while since I posted this, but it is worth noting that this fix is truly only a temporary fix.  I tend to browse using a VPN, and find that the fix only works for a little while.   Once it runs out, I just switch to a different vpn location and voila, I can browse a little while longer.  Its not perfect, but the Scottish in me doesn't want to pay for Medium at the moment.  

Also, if you have this cookie block in place and you try to sign up for membership on Medium, the link they send you will hang indefinitely.  You'll have to remove the block, retry the link, and things should work.  Just noting.  

Monday, October 06, 2014

Problem Found With Autoenv

When I first posted about virtualenv a few months ago, I was in the middle of learning to use and configure it.  Since then, I have created a script to create my basic project structure (including creating bitbucket and/or github projects) that also initialized git for you.  All in all, I wanted to be able to run the script and have it setup everything so that I could just start my coding.

As I was using my script though, it did what I created it to, but unfortunately I started to notice that after it was run, my environment would "activate" (quotes used on purpose) when I changed to the project directory, but not really.

Early on I gravitated towards using autoenv to auto-activate my environment when I simply cd'd into the project directory structure.  While this is a really cool tool, it is supposed to source $project_dir/bin/activate to activate the environment.  Unfortunately though, when I do a "which python" after changing to a project's directory, the system python path is provided when it should be referencing the python in the projects environment.

In the testing that I have done, this seems to be a bug with autoenv.  Thankfully though, its not the type of bug that is a project killer, just an annoyance.  For the time being, I plan on adding a sourcing of the activate file to the .env file in each project, as doing so seems to be a valid workaround.  I am also researching this to see if anyone has reported it to the developer.  If not, I will open an issue with them.

One note though, is that once activated via my work around above, you will need to deactivate the environment when you are done and exit the projects directory structure.  This can be done by running the 'deactivate' command.

 
Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.