|
Just go to dx.com and mooch around.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
4G LTE is on the move all over Europe. Obviously, the speed varies a lot from one place to the other, and my country, Norway, is one of the front runners. Anyway, expect LTE to be The Dominating Technology in most of Europe a few years from now. 3G (with about a dozen variations) was just a warming up: Gradually the 3G frequency bands are taken over by LTE and the transmitters replaced.
Then comes the problem: Take a look at LTE frequency bands[^]: There is not a single LTE frequency band common to US and Europe. (One European band, 2600 MHz is used in Canada - but lots of areas in Europe are covered by other frequencies, not 2600 MHz. I guess the same applies to Canada.)
I don't think there is any LTE capable phone on the market that supports all 40+ frequency bands - they all come in different variants for the various regions of the world. Tourists are frequently warned: If you come across a really good offer in a different continent, chances are that when you come back home, only 3G will work - and 3G is yesterday's technology. When 4G was opened in Norway, a number of people tried to save money on buying 4G phones cheaper in the USA, and wasted their money: The phone could not be modified / upgraded.
(Maybe this is a matter of firmware only, but I am not so sure. E.g. handling lower frequencies, down to 450 MHz, might be costly in terms of antenna size etc, so a cheaper / more compact solution is selected in markets where 1900 is the lowest frequency used. Or, in markets where the highest frequency used is 1900, they choose cheaper solutions that cannot handle 3700. I have come across several electronic products having identical looks, and model designation, in Europe and the US, but when you open them, the electronics are significantly different. I would expect the same from a mobile phone.)
If you insist of using the same phone in Europe and in the US, you won't have many options, if any at all! If you want an LTE phone that works in Europe, you should probably buy it in Europe. You might find models in Asia handling most of the European LTE bands (look at the last table in the Wikipedia article), but don't expect it to work in North America.
|
|
|
|
|
Member 7989122 wrote: Maybe this is a matter of firmware only, but I am not so sure. E.g. handling lower frequencies, down to 450 MHz, might be costly in terms of antenna size etc, so a cheaper / more compact solution is selected in markets where 1900 is the lowest frequency used. Or, in markets where the highest frequency used is 1900, they choose cheaper solutions that cannot handle 3700. I have come across several electronic products having identical looks, and model designation, in Europe and the US, but when you open them, the electronics are significantly different. I would expect the same from a mobile phone.)
It's not even just upper/lower range limits; there're limits to how many bands and signal modes you can pack into a single RF chip. In the US this is most visible in comparing otherwise identical ATT/TMobile phones with their VZW/Sprint equivalents; they'll use different RF chips that have overlapping but not identical band support. (Generally the latter will support legacy CDMA/EVDO 2/3g networks, while the former will eschew those in favor of a few more GSM bands.) The total number of bands that can be supported is going up (it used to be common to need 4 USA models, one per major carrier), but so are the total number being used. This is also being complicated by virtually every legacy band being used to carry LTE somewhere in the world (although which are switched over first is highly variable).
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
swampwiz wrote: As for battery charging, it's been my unfortunate experience with mobile phones that they all seem to have a proprietary charge specs and it's difficult to find a replacement charging adapter; of course, this could be because I keep using a mobile phone for years, well past its commercial obsolesence.
This is very much a case of your being woefully out of date. About a half dozen years ago the EU mandated the use of USB over proprietary chargers and cables for phones to limit waste production. Other than Apple, no one went the proprietary port to USB dongle route, and supporting multiple different plugs for the rest of the world wasn't worth it; so everything else charges over USB now. You've still got some complexity from USB-B vs USB-C microports (USB-C is the future though and virtually all high end phones launched this year are using it, it should trickle down to the rest of the market over the next year or two) and various incompatable fast charge options proliferated ahead of the USB Group coming up with their own high power charging options; but even there almost any USB device/charger pair will fall back onto lower power standard compliant options.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: About a half dozen years ago the EU mandated the use of USB over proprietary chargers and cables for phones to limit waste production. Other than Apple, no one went the proprietary port to USB dongle route, and supporting multiple different plugs for the rest of the world wasn't worth it; so everything else charges over USB now
Eeeh, well, sort of... My old Samsung has a charging cable with a USB A plug in one end and a proprietary one in the other. (The cable has no electronics, as far as I can see.) If I loose that cable, I have to order a new one from Samsung. If I run out of power while away from home, I cannot use any other USB charger.
The EU requirement was for the USB B Micro plug. Not the USB B mini. Not the original B or USB3 B (for obvious reasons). Not the USB3 B Micro. Those moving over to the C plug mess it all up - as if the USB plug people haven't done enough of that already!
And then, some manufacturers go for wireless charging, with another four competing standards.
The good thing about standards is that you have so many to choose from... Before I gave up SCSI, I had bought cables/adapters for eight different plugs, but I was told that there were fourteen available, if you count them all. USB isn't quite there yet, but I guess within a couple years it will overtake SCSI in number of plug alternatives.
There is this story about the electrician, the engineer and the IT guy arguing about whose trade was the oldest one. The electrician tapped on the Holy Book: God said 'Let there be light!, and there was light - imagine the cabling job required for that! The engineer went even further back: In the beginning everything was chaos, and God made order of the chaos - a truly impressive engineering project. Then the IT guy stood up: And who do you think was responsible for the chaos?
|
|
|
|
|
You should consult a psychic.
Jeremy Falcon
|
|
|
|
|
I have been using Node.JS for a long time now. I jumped on the hype train with everyone else and now regret it. JavaScript is a pain. NPM is a pain. The belief that everything should client rendered SPA is a pain (yes I have heard people say this. Now Node isn't too terribly horrible, but it is often overkill, and other times just annoying. I have decided that I am going to stop using Node for everything and perhaps stop using Node primarily.
I primarily freelance. I do anything from simple sites for small businesses, more complex sites with features like e-commerce, and even some mid-sized web applications. I want to learn something that is mature, but not COBOL mature and can handle anything from small sites to larger applications. I also purposely want to avoid learning any of the "hip" languages for right now (i.e. Go)
So far, I have had much trouble debating what to learn. At first, I looked towards Ruby on Rails. I actually don't mind the Ruby language, and Rails has been popular for a while now. I gave that option up quickly, though. After a little research, I decided RoR was dead, at least in respect to new projects. I can't find very many RoR programmers that are not moving to Elixir and Phoenix. ASP.Net was ok. ASP.Net WebPages provided simple support for small sites needing only a little information from the backend. ASP.Net WebForms provided a step up for bigger websites needing more complex features and ASP.Net MVC could be used for larger websites and complex web applications. There were a few issues, though. I hate being tied to Microsoft. VS is great and all, but I would be forced to use SQL Server and it would be hard to find hosting. Plus, with the release of ASP.Net core, WebPages and WebForms are gone so ASP.Net will be overkill for smaller sites. I next looked at Python. The language is pretty good. and I don't see Django or Flask becoming obsolete too soon, but I am not sure about that. From what I've seen, Python will be primarily a data science language and will shy away from web development. I have recently evaluated PHP too. At one point I was a PHP hater, but the language and it's tooling seem to have improved greatly. PHP is great for simple sites, but if I need a more complex site or application, there are great frameworks like Laravel or Symphony. For someone without much exposure to PHP,
however, it seems a little hard to learn. Not in the aspect of language complexity, but in the aspect of outdated tutorials, documentation, etc.... Most PHP7 tutorials I see assume you were a PHP5 developer and to many tutorials make use of obsolete technologies such as the old MySQL library.
So at this point, the only two I have seriously contemplated are PHP and Python. At this point, I am stuck on which to learn. I really like Django, but I am not sure if it will last. PHP is time tested, but I'm waiting for many tools to get up to date with PHP7.
What do y'all think? Are there options I should have evaluated that I missed. Given my requirements listed throughout the first few paragraphs, how can I best make a decision between PHP, Python, or anything else?
i cri evry tiem
|
|
|
|
|
Python is great for small things. Python sucks for large development because productivity is crippled by having to run code (either manually or by writing unit tests) to fix stupid syntax errors that a compiled language would tell you about right away (or even the IDE).
Django, like Rails, is an opinionated framework. New releases break old code, at least major new releases, from what I've seen. We're stuck on Python 2.7 and an old version Django because everything will break if we upgrade and also because of the customization that was done to Django. And Django is written in Python, see first point.
Ruby is an awful language actually. RoR is an interesting but opinionated framework, like Django, and I don't buy into their opinions.
ASP.NET/WebPages/WebForms all just seems like overkill to web development, especially when integrated with Entity Framework, its potential tie in with IIS, and its interdependency with SQL Server.
So, in my equally opinionated world, but at least they're my opinions:
- I don't use ASP.NET/Web-whatever, or IIS. I use C# for server development and have a robust and efficient set of modular components that I wrote for serving the web pages, js, css, doing logging, emailing, configuration management, etc.
- I have a boilerplate library of HTML/JS/CSS and backend C# endpoints that I use for site basics: registration, email, authentication, authorization, etc.
- I'm not married to SQL Server because I don't tie in to frameworks that use SQL Server. But the only other contender that I like to work with is PostgreSQL, the rest I won't touch.
- SPA is not a pain. I've used Backbone at work, it's easy to use if you color within the lines, I also use my own simple SPA js library, and there are some interesting (and small) SPA frameworks out there that I haven't looked at if you don't want to use Backbone.
- I won't touch Angular. I never jumped on the Angular bandwagon, and when I read the A-v2 would not be compatible with A-v3, I was glad I didn't.
- I've found that the real complexity of web development is actually the UI. The mess of HTML, CSS, and Javascript. While the pain of UI itself can't easily mitigated for the non-boilerplate stuff, sticking with some existing frameworks (I'm getting enough experience with Boostrap and jqWidgets to actually do meaningful things nowadays) has helped me a lot when it comes to learning the pain points of said frameworks.
- I have a strict web development process now:
a. develop the DB models with unit tests
b. develop the server REST calls with unit tests
c. iterate a & b until the back-end does what it's supposed to do
d. develop the UI
e. tie in the REST calls
f. fix a&b as a result of real-use-case UI requirements
g. done
I would say (opinionated again) that's it's essentially a task-independent process, it's also fairly language independent, but I love working in C# for a-c, and I deal with js/html/css + Bootstrap/Knockout/jqWidgets for d and e. Backbone I use only at work, might use it for some personal projects, but can't really answer "why would I" sufficiently.
On the server-side, besides my personal library, NewtonsoftJson and FluentMigrator are the only third party pieces I use, believe it or not.
And ironically (or actually, pretty cool) many of the components I've developed for the web server are agnostic, so I also use them for developing WinForm client-side apps that tie in the server as well.
Marc
|
|
|
|
|
Thanks Marc. I've been swimming in the muck that is the current web-dev swamp, and your excellent description was enough to give me enough hope there is a manageable way through this mess 
|
|
|
|
|
What language do you use to write the handlers for your REST calls on the server side? Is it C#? If so, how do you do it, since you do not use ASP.NET and IIS?
|
|
|
|
|
Dimitrios Kalemis wrote: What language do you use to write the handlers for your REST calls on the server side? Is it C#? If so, how do you do it, since you do not use ASP.NET and IIS?
C#
HttpListener[^]
Used in my library like this[^].
Marc
|
|
|
|
|
Thank you for sharing!
Your method (the Clifton Method of software implementation) is really impressive!
By the way, the last link you gave me is missing an "s" from the end. It should be:
https://github.com/cliftonm/clifton/blob/master/Clifton.Web/Clifton.WebServerService/WebServer.cs
Thank you again!
|
|
|
|
|
I use WCF services for json web services with Rest and a simplistic ODATA response syntax. WCF Services are very easy to create. Fast and feature rich. I put a separate service in each dll. One primary project that rolls them up.
Marc is right on to suggest you have layers and unit tests for each. You can use any database, by the way, not just EF with MS SQL.
For the front end, it is all html/css/JavaScript getting data via rest calls. Also, if you research the ODATA standard, you will see this is the way to go.
It is very easy to do. I find mixing front end and backend fine (ASP.NET MVC) but I prefer an architecture that does not mix them.
I prefer the simplicity of knockout over the massive angular frameworks, and as you are not big on a SPA, then I would recommend it. However, angular with a SPA does provide a very good experience, if bloated.
Architecture
[ UI ]-- [ JS MVVM ] -- [ JS Service layer (ajax) ] -- [WCF Message inspector ] -- [ WCF Service call] -- [ Command Manager ] -- [ Repository ]
|
|
|
|
|
I also follow this plan of attack
|
|
|
|
|
I won't dive in too deep. but with ASP.NET you're definitely not tied to SQL Server. It'll work with a ton of different SQL and NoSQL providers.
My preference is C#, ASP.NET and MVC. VS is getting a little out of hand, but VS Code will run on any major platform and .NET Core is platform independent. Lots and lots of work is being put into this and, give or take a few speed bumps while they sorted out v1.0, it all seems very, very solid.
cheers
Chris Maunder
|
|
|
|
|
Do you use MVC on this site Chris ?
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
In parts. We're still moving over.
cheers
Chris Maunder
|
|
|
|
|
There's also Mono with Apache (mod_mono and XSP), which can run ASP.NET/MVC applications quite nicely, and doesn't have to be tied in to SQL Server (As Marc said, PostgreSQL is a very good database server, and has a LOT of plugins).
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
First let me swipe a mystery for you: .NET does not force the use of MS SQL!!!
Every decent SQL/NoSQL has connectors for every decent framework including .NET. And even in has no a native .NET connector, you can use ODBC or OLEDB too... So choosing database and framework are not related really...
I'm an old Microsoft web developer (not old in age but old in experience of almost 20 years)... Used to write web pages in Notepad...
The first step you have to do in becoming a language agnostic web developer is to embrace the idea of the separation. Do not think of your solution as a monolithic one, but pick the best solution for the DAL, the server and the client separately...
After all these years my basic solution for every size of web application is creating a DAL using C# (it has nothing to do with web development and this part of the code is reused almost for every one of my applications), creating a web service (I mostly use C# for this too, but also PHP had it chances) along some standard like REST (I mostly used the MVC pattern here and today I explore the ASP.NET Core to gain multi-platform), the last thing is the UI where the limit is the sky... There are endless libraries with their strength and weakness - you only have to pick your favorite... (I use jQuery for DOM, pure JS for code and a home made variant of bootstrap to visual)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Again, choose a language based on the job at hand.
The Elm language is definitely a worthy contender for SPA.
Elixir (for backend), the Elm+Elixir combination will ensure high performance as well.
|
|
|
|
|
in my humble opinion...forget PHP and Python. Go for Java
|
|
|
|
|
I did Java a few years ago, scared to go back.
i cri evry tiem
|
|
|
|
|
You should give a second chance...Things have improved substantially..I find it extremly productive after the usual learning curve that everyone has to go trough.
|
|
|
|
|
Hi
My advice is don't tie yourself to one language but have a range you can choose from. Love or hate them I primarily use Microsoft tools. My language of choice is ASP.Net combined with jQuery, Javascript, and Bootstrap (or other web UI framework). There isn't any web application (SPA) or otherwise that I can't generate using those tools. I also use AngularJS, and MVC and even plan old HTML and CSS in a text editor.
(I have to say I am not a fan of SPA, nothing against them, just don't see the point. No I don't want to debate that)
Having been doing these web apps large and small apps for a while now I can get the best performance quite easily no matter what tools and technologies I use, and I've worked on some pretty big systems.
If you bear in mind that at the end of the day your browser pretty much expects a server to spill out HTML and perhaps a bit of Java, so the tools you use are almost irrelevant and your choice in how you want your server to spit out that HTML.
Try not to listen to the hype as its all your personal preference. Find a language and tools that achieves your objectives and go with that.
That said you might be swayed buy potential career opportunities. If you looking to build a career look at the job boards for the most popular tools. It will all change again in a few years anyway so just look to build on any experience you have
I see Java/PHP/Lamp etc requested all over the place, it's pretty popular for sure. I don't use any of that and have never been short of work.
There will always be debates on what is the best and its all nonsense. Most is subjective and personal preference and I stopped engaging in such debates years ago.
|
|
|
|
|
As a Java developer, I have to say that popularity [with clients] is not why I chose the environment (if it was, I'd still be using PHP), but because of the ecosystem of *useful* and *well written* libraries. From big frameworks like Spring MVC and Hibernate down to little utilities like OAuth clients and date handling utilities, just about anything you can need is there; just add a line to your maven config and it's downloaded and configured automatically. .NET is *almost* there these days, but doesn't have quite the slickness (NuGet lags a little in usability to maven, IMO) and there's a larger proportion of libraries that are buggy in my experience. But I'd suggest that anything *outside* of the CLR/JVM environment is taking a bit of a risk, because the farther you get away from these environments in which the majority of professional development is performed the more likely you are to find libraries and frameworks that are badly thought-out or are, frankly, badly-written.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
