"""
Cookies and local storage serve different purposes. Cookies are primarily for reading server-side, local storage can only be read by the client-side. So the question is, in your app, who needs this data — the client or the server?
If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.
If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.
"""
So I guess server-side no-JS applications are going to be caught in this crossfire?
Client side apps will be caught as well. Putting a JWT in a HttpOnly cookie is a common pattern. In fact, many people recommend this approach over localStorage for security reasons.
PHPBB era forums would let you authenticate by putting a session ID in the URL. No cookies needed. There are many ways to do authentication without cookies. There's also basic auth. The whole "we use cookies" thing is a weird misnomer to make laypeople understand that the website is talking about the same concept those FUD articles about web tracking have talked about (tracking can be done through thousands of different vectors, no cookies needed).
>So I guess server-side no-JS applications are going to be caught in this crossfire?
No, as nicbou said, the "we use cookies" popup seems to be only required for tracking/advertising cookies.
Impressive tool, but the supporting documentation is what I appreciate most.
I think the prevention guide could be improved by providing an example service control policy that blocks known dangerous IAM actions like ecr:SetRepositoryPolicy for all but a specific security principal.
This is such a good point - in every disaster / zombie movie they somehow have gasoline to run cars but no electricity, when in reality it would be the other way round - any existing gasoline would go off after 6 months.
It's an interesting topic, many view gas station and the oil supply as more reliable.. probably a too-big-to-fail aspect of it. But 'if' it crashes, it's indeed a lot harder to compensate for than electricity.
> It's easier to set up back yard solar panels than a back yard fuel refinery.
If you have lot of open space with sun exposure, true.
For the average small yard, it's easier to buy a 55gal drum of gasoline and a manual pump if you can anticipate the need.
Growing up in hurricane country, it's something some people did. Buy a drum in the summer and store it. If it wasn't needed, just use it up after November (end of hurricane season).
> For the average small yard, it's easier to buy a 55gal drum of gasoline and a manual pump if you can anticipate the need.
If someone on planning on doing this, make sure to get 'boat' gas or ethanol free gas. Gas containing ethanol is not made to be stored and separates/attracts water.
> CPSC also warns consumers that private storage of more than a limited amount of gasoline (usually five gallons or less) is illegal in many areas, and subsequent fire damage may not be covered by insurance policies.
That article (from 1979) indicates that the only legal restriction is that it must be dispensed into an approved container.
More recent advice from the API indicates that fire codes usually restrict the storage of more than 25 gallons (~95 L) at home. Many people in rural areas would have orders of magnitude more than that.
So it seems that, in the US at least, it's not illegal all over.
Your first link says the exact opposite of your claim. It says it's legal to store above 30L and below 275L of petrol if you inform the local Petroleum Enforcement Authority.
Even above 275L, it says you need a license - it doesn't say it's illegal.
Fuel does go off, but if you have reason to store it, you probably have a use for it, so as long as you cycle the fuel, you can store an emergency supply indefinitely.
'Even above 275L, it says you need a license - it doesn't say it's illegal.'
Its commonly said 'it illegal to possess plutonium', but obviously someone does operate nuclear powerplants, and thise are people with the right licence. Same applies to drugs, explosices, etc.
The question is - are requirements of the lisence realistic for you to meet as an average homeowner?
You can still store up to 275L without a license, which is surely enough for the use case we're discussing. I can't help but think you're nitpicking.
However, I picked a random Council to see, and it looks extremely doable for a homeowner with the space to do so to get a license to store up to 2,500L. It's not even particularly expensive (£44 pa)
We have a solar array on the roof. It’s great. But the dc->ac converter needs the grid to be active to do its conversion, so when the power goes out no solar. (I suspect it syncs with the grids 60hz...)
If you include a battery backup in your system, you can run without grid power.
When I worked at a power monitoring start up we had a demo house that was charging an electric rav4, so it’s possible.
Yeah, that's the actual reason. I've seen someone use a small Honda generator to generate the frequency required to trick the solar generator into going... it's a weird setup because you basically tie in your generator using a breaker, so both generator and solar can be enabled at the same time.
Most home solar installs are grid-tied. No utility power, no solar power.
It simplifies the system a lot, because the grid provides "instantaneous" load matching for your house. If the inverter is sourcing more current than your house is sinking, the grid will sink it. If the house is sinking more current than your inverter is sourcing, the grid will source it.
When there's a utility outage, you need something else to provide the load matching. Either a local generator, or a battery is common; but either way, it's a lot more expensive.
It is a more complex and expensive inverter that can operate both isolated from the grid and in sync with it I think because it has to know when to do which and if it is outputting power how can it tell if the system is live because it is grid tied or because it is keeping the system energized itself.
I think they need external signals to tell them which mode to operate in.
Maybe the external system sees the frequency and voltage dropping or lower than normal range and decides to disconnect the load from the grid and opens a breaker and tells the inverter to operate in isolated mode.
When the external system sees the utility power is good again it could tell the inverter to shut off, close the breaker to connect the load to the utility, and then the inverter can go back to grid tie. The outage can be very short unless the load is large motors they don’t like the instantaneous change in phase when switching between different sources that are out of sync.
It's a safety reason. If the company disconnect the grid upstream to work on it, and your house is still powering it, they have a problem. You need extra equipment to automatically disconnect the house from the grid too.
I understand why grid-tied systems are built this way, but from an engineering standpoint this is really inefficient. Converting from DC to AC and back to DC, for no reason. In fact, most solar controllers are already designed to use and charge batteries.
It doesn't help that most car manufacturers use locked battery charging protocols that don't allow you to easily change this process.
AFAIK other car makers in the US use either CCS or ChaDeMo.
In Europe, all car makers (including Tesla) support CCS.
CCS allows DC charging and has support for load balancing, so I assume it could be feasible to create a home CCS charger that directly charges an EV with DC from solar panels.
However, considering how expensive power electronics are, and how difficult it would be to integrate such a charger into an existing solar installation, I have doubts that many people would buy such a charger. Also, I don't really know how CCS works in detail, so I may be totally wrong about this.
solar panels are the wrong dc voltage, so some sort of conversion is needed. I'm no EE, but my understanding is you go through AC and a transformer anyway in most cases.
Virtually all off-grid solar installations use some kind of an MPPT controller with a battery setup. The controller is always charging the battery (when there is power output from the panels), and the consumer power output is supplied by the batteries. This way you get much higher peak current output than the panels could provide, you also ensure stability.
In fact, many cabin installations don't even use inverters to convert into AC. They instead use DC appliances. So no, going through AC makes no sense in this scenario.
As for DC voltage levels, that of course is dependent on solar panel configuration and battery cells configurations/packing. Virtually all electric cars have a built in charger with a switching power supply that's already doing the DC voltage conversion. What I was remarking was that there is a lot of duplicate electronics that perform the same function and that a lot of intermediary steps can be eliminated.
Off grid is going to be designed to fit and probably cheap. Not always best. If you panels are near the batteries and near the load what you say can make sense (though I wouldn't be surprised if the charger had a AC step internally, that is clearly optional)
That isn't what you would do for anything tied to the grid. This is far more common (economies of scale mean the parts are cheaper). There you would take advantage of AC's ability to change voltage easily to allow the panels to be farther from the rest of the system. You would also want to use the grid as a backup for any system failures in the solar setup.
With a charger that goes down to 750w you can charge your ev off grid with an inverter.
I currently do it with 12 100w panels. I run ac/dc converters to supplement additional dc from the grid to charge at 1500w, but have a 750w charger for emergencies that will charge directly from the sun with no grid. It does require a small buffer battery to work reliably.
at 750W, even with perfectly efficient energy transfer, you're looking at adding ~2.75 miles of range to your car every hour it's charging. That means during winter, if it's sunny, you might be able to charge your car all day and get 25 miles from it.
You'd be a lot better off with a jerry can and a $500 gasoline generator....
The article is citing needing 6-8 panels between 320-330 watts to charge a Tesla Model S; 8 if you live in the northeast United States (it's not backyard orientation, it's about where you live geographically), 6 if you live in the southwest United States. The "small" Tesla panel arrays that I mentioned are 4.08 kilowatts [1], which is more than enough even in the northeast to charge a Model S, or any EV. They take up 240sqft, which would fit in most backyards, although a roof mount would of course be preferable both because it'll get less shade and because it won't take up backyard space, unless you have a lot of open backyard space away from any existing structures.
Really. There's a reason Tesla sells solar panels, and it's because they can charge the cars Tesla makes. They can also lower your electric bills (or drop them to zero, or make you money depending on the region you live in), since even the smallest panel array they sell produces more electricity than an average American driver needs per year for an EV.
Do you own Tesla solar panels? I've heard mixed reports about them. I live in Northern California where there is a big solar presence but most of the solar people I've spoken to (installers and owners) say Tesla is too expensive and not particularly great.
I'll be doing solar panels on our roof when the battery storage tech becomes viable and PG&E start being sensible about individual electricity production.
I don't own Tesla solar panels! I'm just going off publicly available info. I'm willing to believe that Tesla is not competitive on price, although I would be surprised if their wattage numbers were fake.
I really think there is an under-addressed niche here. I haven't tried your product yet, but I was pretty hopeful when I saw this posted here. That being said, I have some feedback already:
- $29/user/month just feels too high. My per-service spend on any other SaaS ranges from $3/user/month to $18/user/month. What makes this service so valuable that I would spend more on it than any other SaaS that supports my business?
- There's obviously some overlap here with Jira. It would really be nice to see a page on your website showing what RoutineOps can do that Jira can't already do.
- Some people really, really like learning about products by video instead of text or screenshots. Videos aren't as information dense, I know. But in the past I've found them useful in my goal to influence budget holders.
- Your screenshots don't illustrate how the recurrence flow actually works. If I schedule a new task every day and then do nothing for seven days, do I have one task or seven?
- There is no obvious way to contact you. The page footer isn't just spartan, it's barren. It's missing some really essential stuff. Privacy policy is another important one.
- My primary use case for scheduling and tracking recurring work is based on audit compliance. Are you intending to address that market segment? If yes, then tell us.
- When I'm buying software to help with audit compliance, it's especially helpful to know whether the SaaS organization I'm purchasing from also has passed some audits (like SOC 2 or ISO 27001) I guess it's too early stage for you at this point, but something to think about.
- Thanks for the feedback! Really appreciate the thoughtful notes, particularly on the marketing site which is admittedly very barebones right now.
- Also super helpful note on the pricing - honestly hadn't put too much thought into it yet as I'm still validating that it solves a real problem. Agree that I will need to experiment a bit with pricing once the team option is available.
- As for audit compliance - I definitely had that use-case in mind eventually, but I would love to hear more about your specific use-case and requirements
Agree on the pricing. It looks like a very nice tool but since it's at core just a different way of organizing/bringing together information I can store in other places, at that price point I'd simply improvise with the other tools we had.
As CTO for an enterprise, I’d shared this to our chief of staff as a possibly interesting lightweight tool to pilot.
Then I saw they want a multiple of retail or enterprise cost per user of full Microsoft O365 (Office) which includes One Note, Wiki, To Do, and Planner as well as native mobile apps for these.
Also per your last bullet on SOC 2: for us, it’s not just helpful. We require the reports.
For anyone thinking of starting a SaaS enterprise productivity tools business, here is the benchmark enterprise sourcing and procurement will compare you to:
Office 365 Business Essentials. This comes in at the cost of at $5 per user with an annual commitment or $6 with a monthly commitment. It also comes with access to Microsoft Exchange, OneDrive, SharePoint, Planner, and Hub. This plan only includes access to the web and mobile versions of Word, Excel, and PowerPoint.
The second, more expensive, option to getting Teams is with Office 365 Business Premium. This plan comes in at the cost of $12.50 user per month with an annual commitment or $15 per user per month with a monthly commitment. With this plan, you not only get Microsoft Teams, but also SharePoint, OneDrive, Exchange, as well as the option to install Office on all of your PCs, Macs, and phones.
For larger organizations with more than 300 employees, Office 365 Enterprise would be the best way to get Microsoft Teams for free and to all employees. It is included with the E1, E3, E5, and F1 plans:
Look at the enterprise IT management, security, and compliance value they’re offering at each pricing level. Really think about it:
Enterprise F1 is the cheapest since it is more about “frontline” workers and access to online services and apps. On the other hand, Office Enterprise E1 is also reasonably affordable, as it includes all the Office 365 collaboration services, as well as additional controls for IT professionals. In the middle is Office 365 Enterprise E3, which includes the full Microsoft Office suite of applications, and access to additional Office 365 collaboration services. Finally, with Office 365 Enterprise E5, you get the best of the best, which is everything included in all the other plans, and additional advanced security and analytics features.
Me too. But I doubt it will ever happen without regulation.
The only development in this space that I'm aware of is from a South African company called root. You can run custom code before/after transactions through their credit card. https://root.co.za/card
Storing the lookup map on disk as a JSON-encoded dictionary seems less than optimal for package size and module load time. Two plaintext files (M.txt and F.txt) would be simple and more efficient on disk. The text is also highly compressible -- that could further reduce package size. These things might matter if the package is used in a Serverless environment.
Also, do you think there could be value in identifying classically androgynous names?
Thanks for sharing your feedback! Great idea on using .txt instead - I'll make a change for that. (My first time sharing a package I've prepared on github, so I'm a noob with that kind of stuff)
There are names in the current json file classified as "N" which stands for non-binary, but the frequency is quite low. "N" is based on if the frequency of "M" == "F" or if the frequencies are within a certain magnitude of each other. (magnitude calculation is based on proportions testing) With that being said, maybe it'd be worth adding functionality for a user to upload their own gender_lookup file?
Ah, I didn't see the N records originally. That makes sense!
Because I'm enthusiastic about data structures, and now that I've finished my work day, I thought I'd come back with a few numbers to support my earlier comment. The package size can be reduced by 90% by saving the names as compressed plaintext.
On my reasonably modern laptop, it takes over 700 ms to unmarshal 5MB worth of JSON. But it takes less than 100 ms (85% time savings) to read the whole file and compare strings.
$ time jq -r . >/dev/null gender.json
real 0m0.764s
$ time grep -E '^(NIC|PAUL)' gender.txt
real 0m0.091s
When working with large datasets of items that are mostly the same size, sometimes it's useful to use fixed-width records to enable random indexing into the file. Of course, this is a small data set so it's not really worthwhile to pursue such optimizations. So just for fun, here's an analysis of how long the names are. 99% of names in this set are 13 characters or less. Representing short names as fixed-width records and long names as an appendix would use about 2.5 MB (50% savings compared to JSON).
https://github.com/yashsinghcodes/wik/blob/main/wik/info.py#...