joelennon

Works for me without signing in https://cloud.laravel.com/docs/intro

Like others I've tried this before but it's just too much effort to use this approach as you spend a lot of time rejigging your calendar as it's so granular with the time dimension. Not to mention trying to coordinate it with meetings and your actual schedule.

That said, I do like using a calendar approach for tasks. I've previously used TeuxDeux successfully - it's basically just a todo list per day and it makes it easy to plan things ahead of time and move them around as reality bites and you need to move it to a later date.

Not a CEO but co-founded a company that had a successful exit. Happy to talk sometime.

One thing I'd say is to take anything you hear from any given indiviual with a pinch of salt. People love to give advice and will often sound authoritative about subjects they have no expertise in. Everyone's experience will also be different, and people tend to give advice based on their own anecdotes which may be completely irrelevant to you. You see it all the time where people try to mimic the actions of others who have had success, only for them to fail miserably trying to follow the same path. These conversations can shed interesting ideas and thoughts, but make sure you don't treat them as gospel and instead use them to help figure out your own view.

Signed URLs (or pre-signed URLs) typically expire after a short time frame. The idea is that they exist for long enough for the object in question to be retrieved in the application, and they then automatically expire. Although they don't typically have a single-use limitation, this is often the intention a developer has when using a pre-signed URL.

ExtJS was way ahead of its time - while it was most famous for its grid component, the data package, tooling ecosystem (long before we had node) and component architecture was amazing. Its learning curve was tough, but it was so worth it when you got to grips with it.

Jack’s post acknowledges what most of the community felt for years - the biggest mistake was alienating the developer community while trying to chase commercial success. The irony is that ExtJS and Sencha could have been hugely successful commercially if they had approached it differently. Instead the only people building on it were usually people working in large corporations, and even those would never use it for hobby projects outside of work due to minimum purchase of multiple seats to use the non GPL license.

I look back fondly on my time using ExtJS as a developer. They had some of the smartest engineers around working on the framework, a great community in spite of Sencha’s best efforts and I learned a metric ton along the way. Who knows where it would be today if it all went a little differently!

Nice idea. I'd recommend adding some kind of visual indicator when it's in a loading state - at first I thought it wasn't working but it was just slow to respond (probably because it's close to the top of HN right now...)

Q4 2021 revenue by geography:

* $15.826 billion in US/Canada

* $8.357 billion in Europe

* $6.244 billion in Asia/Pacific

* $3.244 billion in Rest of the World

The software world today is also very different. SaaS has become the norm because the typical user experience for software products spans multiple devices and is a far more connected experience that relies on services carried over the Internet. When you add server-side services into the mix, you have a much-increased variable cost to delivering software that is more difficult to absorb in a once-off price.

While many of us here would prefer the idea of owning and licensing software in perpetuity, the reality is that most users don't care and are typically more price sensitive to the point that they will prefer to pay a small amount monthly than pay a large lump sum once. The monthly pricing mechanism also provides a safety net, as you can stop paying at any time if a product no longer provides utility or if you straight up can't afford it.

At the other end of the spectrum, SaaS works very well for business. Larger companies always paid recurring fees to software vendors anyway - typically as support and maintenance, because they need SLAs and commitments that ensure continuity of being able to use the software in a reliable manner. In the past, these were usually a recurring add-on that was paired up with a major up-front cost. Today, it's reversed where you now might pay a small once-off cost for implementation or delivery, but the bulk of the pricing is weaved into the recurring subscription cost. This works better for most businesses.

Also, a much higher percentage of software makers these days are doing so on the back of venture funding. The north star metric for most venture-backed companies is annual recurring revenue, so a subscription model is almost the default when it comes to a venture-backed startup. When a company is focused on rapid and high scale growth, having to start every year at zero makes it significantly more difficult to succeed.

Workvivo | Cork, Ireland | REMOTE | Front-end & Full-stack Engineers, Product Owners/Managers | https://www.workvivo.com

Workvivo is an employee communications platform, designed to bring your workplace culture to life. Think of it as a social network, intranet and employee app solution all streamlined into a modern digital employee experience. Our mission is to help companies drive engagement in their workforce and better align employees with the goals and values of the organisation.

We're based in Cork, Ireland but are working entirely remotely since the pandemic and hiring internationally for most roles. Our team of 30 are currently spread across Ireland and the Bay Area. We raised a $16m Series A earlier this year, and are currently hiring across product management, engineering, marketing, customer experience and sales. For product and engineering roles we are looking for mid to senior level experience at this time.

Tech Stack: AWS, Laravel, PHP, MySQL, Redis, Elasticsearch, React, React Native, GitHub

Reach out to me directly if interested - my email is my first name at workvivo.com.

Working people in Ireland also pay high taxes on their income.

In Ireland you pay 20% income tax on the first €35,300, and 40% on income above this amount (if you are a single person, there are different cut-offs for married people and one-parent families).

You also pay an additional Universal Social Charge on all income over €13,000 - between 2-8% depending on your income level, or 11% for self-employed income over €100,000. Add on pay related social insurance (PRSI) of 4% too.

I’ve been using Dracula everywhere for years and love it. I’ll buy this purely to say thanks, getting a shiny new theme is just a bonus. Fantastic work, thank you.

Yeah I get that, but rather than Google opening it up for open registration and having the usual domain land grab, they could have created domains for each action and allow service providers to register intents in their services for each action. It's going to make discovery of actions much harder if there are different actions for different providers. It will also mean the usefulness of the pattern will be limited based on the services I choose to use.

In your example - if I prefer Domino's to Pizza Hut, what do I go to? I need to go to pizza.new to discover that it's linked to Pizza Hut and then try to figure out what Domino's action might be. In the end I'll just end up going to the main site instead. I think the value of this concept is completely nullified by binding the actions/domains to specific providers.

I like the concept behind this but I think the implementation is flawed as it binds the actions to specific providers. For example - repo.new only creates repos on GitHub, playlist.new only creates playlists on Spotify and the music.new thing for OVO Sound is just odd, being specific to a custom cover art generator thing.

For me, the better implementation would be where for each "action" there are numerous providers and at a user level you could define which one you want to use. So user A goes to repo.new and gets redirected to GitHub, user B goes to GitLab, user C to Bitbucket and so on. The first time you go to the action you're prompted to select which service you want to use by default and from then on you go straight through.

I love the concept of this - I live off temporary lists and have tried a lot of different approaches to them - pen & paper, fancy pants notebooks and diaries, Apple Notes, Sticky Notes, full on GTD apps.

For me personally the perfect app just needs to stay out of my way most of the time. My lists are typically what I want to get done today or at most this week - I don't need reminders or nagging, repeated items, subtasks, fancy formatting or complex UIs. Just a list that I can bring up quickly and hide even more quickly.

The one thing that's missing for me right now (and I can see you're already on the case) is an iOS app with iCloud sync. When that's available I could definitely see myself replacing Apple Notes with this.

On a side note (sorry, couldn't help it) I was browsing through the other apps you have listed in the footer and some really nice looking apps in there! Nice work! Definitely going to give TeaCode, ScreenFocus and Expressions a try.

You can buy a Windows code signing certificate from DigiCert for $74/yr (EV certs are $104/yr) by going through this link - https://www.digicert.com/friends/sysdev/ - much easier to swallow than the standard $499!

While supporting SSO authentication is relatively trivial via SAML2, which is supported by virtually every identity provider solution in the market, configuring this is likely a frequent point of support contact and configuration problems.

Something that is typically much less trivial is user provisioning from an identity provider. Most companies availing of SSO will require an automated user provisioning process also be in place. While the SCIM standard is pretty good, and support for it is getting better, implementations of it in identity providers are quite varied and often incomplete, not to mention poorly documented. Companies often also need to provision data that is not stored in the identity provider, so you can imagine the challenge in providing alternative solutions to make that work.

As others have already pointed out, it’s far more likely however that vendors see the requirement for SSO as a signal that a company is larger and falls more in the “enterprise” tier of pricing, allowing them to instantly provide something of value at a higher pricing point. SSO is treated much the same as things like premium support and SLAs - you charge extra because the customers who want it can afford to pay for it.

There is no one size fits all answer to this question. What’s your definition of success? Owning your own business that pays you an above market salary and allows you to live comfortably and independently? Or do you see success as growing to being a huge global corporation? Do you want to start a company that targets consumers, small to medium businesses or large enterprises? There’s a ton of other factors that have a huge impact on a potential roadmap for success.

One bit of advice I’d offer is to know going in that software development is likely to be the least of your problems when running a software company - especially for a software engineer. Your real challenges lie in sales, marketing and customer relations. If you’re not successful at these aspects of the business, it doesn’t matter how good or bad your product or code is.

I love Vue and React. It's the UI layer where things don't match up, however. There are plenty of examples of UI frameworks, some which sit atop React/Vue, that on the surface look to have everything ExtJS offers. Ext had hidden strength behind the scenes though. The Ext.util.Observable pattern for event handling; the Ext.data package for binding component data to server-side back-ends using Ajax, REST and SOAP proxies; under appreciated features such as keyboard navigation and state management with options to persist to cookies and local storage. At the time it felt bloated and the learning curve was crazy, but looking back on it in an age where heavy client-side JS apps reign supreme, it actually doesn't look all that bad.

I imagine because there was no source to back up the claim. There's definitely been an exodus of staff from the company in recent days, but it's not clear what the terms were. For some tweets from former Sencha staff who have departed over the past few days see my comment on another thread:

https://news.ycombinator.com/item?id=15365797

Edit: It certainly looks as though the entire team was let go based on the LinkedIn post you linked to in your edit.

Sencha were working on a project called ExtReact that allowed you to use ExtJS components in React, replacing the JSON-style component declaration syntax with JSX. This would have been pretty amazing - as ExtJS' biggest strength was always the variety and depth of their components (especially the grid).

It wasn't a last ditch effort, the decision to change the pricing model happened 3 years ago. I think the community would have accepted a reasonable rise in price, it was the decision to mandate a minimum purchase of 5 developer licenses that sealed their fate.

Sencha's biggest failure was not building developer mindshare. If they wanted to sell commercial widgets, they should have done just that - their grid was pretty amazing and is probably the feature that led most people to discovering ExtJS in the first place. Instead they tried to sell an entire framework, with an entirely custom approach to building software. For that model to succeed, they should have made the framework itself free on a liberal open source license, and focused harder on selling services, extensions and tools around it. That way, it would have been embraced by more developers, widened the talent pool and encouraged their big corporate customers to expand the scope of its use in their companies.

I think most developers who used ExtJS will have love/hate memories of the framework. I mostly used the framework from 2007-2014 at a previous job, and at the time the extent of most developers' JavaScript knowledge was how to manipulate the DOM with Prototype, jQuery or a similar library. ExtJS was a whole other animal compared to that with its own Java-inspired class system that sat on top of JS, a JSON-style declarative approach to design UI layouts and an extensive data model, store and proxy system that was actually incredibly powerful.

This day was always going to come, however. Sencha's commercial side has always had a habit of making bad decisions, and have always focused on attracting companies rather than developers. This led to initial success on the enterprise side of things - they had a large percentage of the Fortune 100 on their customer books. The problem was that developers didn't use ExtJS outside of the enterprise setting. This was primarily due to the decision to use GPL for the open source license and later to completely alienate individual developers by introducing a 5-developer minimum purchase for commercial licenses. Although I was highly competent with ExtJS and Sencha Touch, I never used it on any side projects mainly because of these issues. All of this meant that when it came to hiring developers with ExtJS experience, it was always a struggle, and I believe it is for this reason that it never took off outside of the big corporates.

I don't believe this is the reason. Apparently most of the existing team are going. Some key community members and developers' departures are already confirmed.

http://existdissolve.com/2017/09/a-fond-farewell-to-sencha/ https://mitchellsimoens.com/next-chapter-in-2017/ https://twitter.com/dongryphon/status/911278681611370496 https://twitter.com/AnimalNige/status/911152490380451840 https://twitter.com/evantrimboli/status/910988537763323904 https://twitter.com/elmasse/status/906243331541360640 https://twitter.com/LemmonsGrab/status/911703530716618752 https://www.glassdoor.com/Reviews/Employee-Review-Sencha-RVW...

Idera (the company that acquired Sencha) own Embarcadero, the company who publishes Delphi. There's a third-party product called uniGUI for building Web applications with Delphi that heavily leverages ExtJS at the front-end. I suspect this has something to do with it.

At the time we were thinking about Vue.js vs React, we were also considering rewriting our mobile app and React Native looked like a really good choice. That was a big plus for React since Vue.js didn’t have anything remotely stable that resembles what React Native is trying to do, so the possibility of reusing code between the web and app clients was a huge plus, but I decided that I wasn’t going to consider possibilities that might or might not happen. After all, from my experience, with Node.js I reuse a really insignificant amount of code between the browser and the server.

The main benefit of using React if you are considering using React Native is that you and your team won't need to learn another framework in order to build native mobile apps for iOS and Android - if they know React already, they'll be up to speed with React Native very quickly.

https://programmingpodcasts.com - it's a directory of software dev and related podcasts. Haven't ruled out monetising it and to be honest maintenance is almost zero as it runs on autopilot. I'm it's biggest user, use it everyday.

Tread carefully starting a business with someone you don't know. If you decide to forge ahead, you'll need to get to know the person not just professionally but personally. I've seen several co-founder relationships (including my own) break down due to personal circumstances that could probably have been predicted had there been a stronger personal relationship prior to starting out. Above all else, discuss at length "what-if" scenarios for every conceivable outcome, in particular the ones that you don't think will happen (like one of you deciding to leave). Get a founders agreement and get a lawyer to translate it into legalese. Put vesting in place so you don't run into tax issues clawing back shares if she decides to leave. Don't wait until you're further down the road, do it straight away.

As for determining if she is the right person professionally, I'd make a list of all of the things that...

1. You suck at

2. You hate doing

...that will be necessary to succeed. In a perfect world, she will excel at many/all of these things and love doing them - allowing you to divide the workload and each focus on your strengths. Don't take her word for it - find out, test her, check references, do whatever you have to do to be comfortable that she is the right person.

I'd say start with Bootstrap and learn Sass. Out of the box all Bootstrap sites/apps look the same but you can achieve some great results by customising the appearance with Sass and coding up some of your own components.

Beware the dangers of the green field. It seems to be every developer's dream to have a green field for a project. You're there at the beginning, so you think you can spend the time to make the correct design decisions early on to ensure you don't end up with the kind of technical debt you've seen at the companies you've worked for before. You'll thoroughly enjoy being a perfectionist, refactoring your code to your own idea of code standard bliss. Immersing yourself in code will keep you busy and make you feel like you are doing important work. The thing is, you're probably not.

Build something, get it in front of customers as quickly as you can and get them to pay you. You'll likely need to do this multiple times to get the right product or features that people actually want and will pay money for. Skip anything nonessential at the start. Focus on the key features that customers will pay for. It will feel broken, but it's only broken if you can't get any customers. This seems like obvious advice, but you're a developer, it will be difficult for you not to aim for perfect before you ship.

Know going in that you will probably be embarrassed by your codebase, but it doesn't matter. When you find the right product formula and need to scale, you'll probably need to refactor or rewrite large parts of it anyway. Even if you build it "perfectly".

Whatever you do, don't use this time as an opportunity to learn some new language or framework. Use whatever you are most efficient with - now is not the time to be learning React/Vue/Angular or whatever else you've been wanting to get stuck into recently. If you can build it faster with mostly server-side views, then do that. Don't stress about picking a language or framework based on future problems like how you'll hire a team - worry about getting that far first. If you're a pro with PHP, use PHP - don't worry about others thinking you're less of a developer because you're not using Go or whatever the flavor of the month is.

Oh and keep it cheap and lean. Don't go building out a huge microservices infrastructure that you may never need. Build a simple monolithic app first and host it on a dirt cheap VPS. Once you get traction you can start splitting it out and worry about scaling individual services.

I've written a little more about this on Medium - https://hackernoon.com/shit-startups-do-episode-1-cbfa73f9c2...

Do you have investors? Check any documents or shareholders agreements you've signed to make sure you can actually do this type of work without breaking an existing contract. At the very least you may need written permission from your investors in order to go ahead.

As for signing an NDA, I've found that often people who require them are pedantic about unimportant things and difficult to work with, so unless there is a very good reason they'd need one I'd be very cautious about getting involved.